Skip to content

Home

Jump to bottom
Cyril VIGNET edited this page Aug 24, 2017 · 36 revisions

Introduction

This wiki is an introduction on the key elements that structured a web payment using Credit Transfer to move funds. This document will successively present: *The credit transfer *The bill presentment *The e-payment *The pull credit transfer

All the document will use the terminology and the glossary of the ISO 20022 when possible and personal terms when applicable. Reference to ISO 20022 messages are done only to provide an idea of the dataset necessary for implementation but the aim of the document is provide a logical view of the system. This presentation is mainly based on experiences of the SEPA Credit Transfer (SCT based on ISO 20022) and the SEPAmail-RUBIS project that extend the SCT.

Nominal flows of the Credit Transfer

The main objectif of a credit transfer is to move funds from the account of the originator (the payer) the the beneficiary (the payee). To do that the following steps are done: 1 the originator initiates the credit transfer to his (her) bank 2 the bank of the originator debits the account of the originator and then sends the credit transfer to the bank of the beneficiary 3 the bank of the beneficiary credit the account of the beneficiary and notifies the beneficiary for the reception of money

During the second processus, they are additionnal functions in order to settle the accounts of the two banks, accounts that are hold at the central bank. Those details are not worth to be detailed for our purpose. Thos functions are operated by Clearing and Settlement Mechanism (CSM).

The initiation of the credit transfer by the originator

  1. By the “customer credit transfer initiation (pain.001)” the customer (Alice) is giving order to her bank to process a credit transfer to the account of Bob a. Alice SHOULD give the identifier of BOB account, mainly based on the IBAN (identifier of the account) and the BIC (identifier of the Bank of Bob)
  2. The bank of Alice is supposed to answer with a customer Payment status report (aka PSR or pain.002). They could be a series of PSR depending of the Status of treatment at the level of the bank : *Status 0 : the bank A receive the file (if done by file, obviously) *Satus 1 : the Bank A is able to read the records in the file *Satus 2 : The bank A is able to process the record : the account (of Alice) has enough money *Status 3 : the credit transfer has been sent and pay trough the CSM (clearing and settlement mechanism)

Interbank credit transfer

The next phase is then described in the draw below, generally using CSM that are often specialized depending of the types of transaction to manage:

  • Mass payment, mainly D+1 settlement ** Could be, net settlement before clearing ** Or, clearing before net settlement with additional mechanism for risk management
  • TARGET 2 for real time gross clearing
  • RIPPLE tomorrow
  • …

The FIToFICustormerCreditTransfer is the pacs.008 of the ISO 20022.

Notification of Bob

The next stage is the information of Bob of receiving the funds.

The “BankToCustomerDebitCreditNotification” (or camt054) is the message used to inform Bob of the credit on his account. Other type of information could be used to inform Bob: the statement (camt.053 in the ISO 20022) or any message given by the bank.

This logical description of the flows could have various implementations depending on the interfaces used by Alice and Bob. Those interfaces could be divided into two categories:

  • Home banking
  • File transfer
  • short message

Limitations of the credit transfer

Operational issues

Two major issues on the Credit transfer service:

  1. Bob is obliged to give, by another means, the amount requested and his account identifiers, such as IBAN and BIC
  2. Bob is not informed of the status of the credit transfer (Alice is by the flow 2) and so is obliged to wait at the flow 4 to be sure that the funds are available. This could be a minor drawback if the clearing and settlement mechanism is very quick (few seconds) with is not the case for most of the existing systems.

Weakness of the credit transfer

The main weaknesses are:

  1. On flow 1, the necessity of a secure validation of the CreditTransferInitiation to avoid fraud. Those authentication mechanism depend on the type of clients (customer, companies) and are up to the bank
  2. Alice should be sure that the account number of Bob (IBAN/BIC) are thos of Bob. If not, it could be a man in the middle attack and the credit transfer goes to another account. As the credit transfer is irrevocable, the protection against this type of attack is important (that is, having a way to securely link the account number and Bob's name)
  3. Alice and Bob should share the same credit transfer scheme

Schemes of Credit Transfer

In the payment industry, a shcem is a set of rule, that contractually binds the actors (banks) that adhere to this scheme.

SEPA Credit Transfer

For example, the SEPA Credit Transfer (SCT) scheme, is defined by the EPC European Payment Council and states the format to be used, the speed of the credit transfer. All those rules are due to have a harmonized usage through Europe and also to comply with legislation. Maximum time from debit of the account of Alice and Credit account of Bob is one day

Instant Payment

A new scheme is under construction in Europe in order to have a maximum time between debit and credit of 10 seconds.

Clone this wiki locally