Home
This wiki introduces key elements of using Credit Transfer to move funds.
- The credit transfer
- The bill presentment
- the Webpayment credit transfer (Push credit transfer)
- the Webpayment pull credit transfer
- the Credit transfer with Payment Service Provider
We use terms from 20022 when possible, or personal terms when applicable. Inline references to ISO 20022 messages have been included 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 experience with the SEPA Credit Transfer (SCT based on ISO 20022) and the SEPAmail-RUBIS project that extended the SCT.
The primary goal of a credit transfer is to move funds from the account of the originator (the payer) to that of the beneficiary (the payee), following these steps:
- The originator initiates the credit transfer at his (her) bank.
- The bank of the originator debits the account of the originator and then sends the credit transfer to the bank of the beneficiary.
- The bank of the beneficiary credits the account of the beneficiary and notifies the beneficiary that funds have been received.
Note: Step 2 involves additional "behind the scenes" activity by a Clearing and Settlement Mechanism (CSM) to settle the accounts of the two banks, accounts that are held at the central bank.
- By the “customer credit transfer initiation (pain.001)” the customer (Alice) requests that her bank initiate a credit transfer to the account of Bob a. Alice SHOULD give identifiers for Bob's account. These are typically an IBAN (identifier of the account) and BIC (identifier of the Bank)
- The bank of Alice is supposed to answer with one or more customer Payment status reports (aka PSR or pain.002).
PSR status codes are:
- : Bank A has received the file (if done by file, obviously)
- : Bank A is able to read the records in the file
- : Bank A is able to process the record : the account (of Alice) has enough money
- : The credit transfer has been sent and pay through the CSM (clearing and settlement mechanism)
The next phase is described in the diagram below, generally using CSM that are often specialized depending on 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.
During the next stage, Bob is notified that funds have been received.
The “BankToCustomerDebitCreditNotification” (or camt054) is the message used to inform Bob of the credit to his account. Bot might also be notified through other means: 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 several categories:
- Home banking
- File transfer
- short message
There are two major issues with credit transfer services:
- Bob is obliged to give, by another means, the amount requested and his account identifiers, such as IBAN and BIC
- Although Alice knows the status of the credit transfer by step 2 of the flow, Bob must wait until step 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). However, most existing systems are not that fast.
The main weaknesses are:
- In step 1 of the flow, it is important to validate the CreditTransferInitiation to avoid fraud. Those authentication mechanism depends on the type of clients (customer, companies) and is at the discretion of the bank.
- Alice needs be sure that she has the proper identifiers for Bob's account and bank. If not, it could be a man in the middle attack and the credit transfer could be sent to the wrong 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)
- Alice and Bob need to share the same credit transfer scheme
In the payment industry, a scheme is a set of rules that contractually binds the actors (banks) that adhere to this scheme.
For example, the SEPA Credit Transfer (SCT) scheme is defined by the EPC European Payment Council. It describes the format to be used and 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.
A new scheme is under construction in Europe in order to have a maximum time between debit and credit of 10 seconds.
Correspondent banking is a generic term for a huge number of bilateral agreements between banks in order to enable Credit Transfers between (almost) any banks. So far, it is not exactly a scheme because the rules change from one bilateral agreement to the next.
As it is quite impossible for a bank to manage bilateral agreements with ALL the banks on the planet, a credit transfer could spring from different banks before reaching the ultimate target. This leads to a feeling of lack of transparency in the system.
Technically those bilateral agreement use the SWIFT network but it could also be other networks or direct connections.
Instant Payment is used in UK.
In our view a payment is a mechanism that links a purchase (by Alice from Bob the retailer) with the transfer of funds (between the account of Alice and the account of Bob).
Unlike card payments, which are specifically designed for payments, credit transfers are not just for payments. They can also be used for "cash management," that is account management.
The bill presentment flow is similar to the previous credit transfer flow, with the addition of initial messages that provide a mechanism to exchange data (identifiers/amount/information) before initiation of the credit transfer.
Two additional messages are defined before the credit transfer in the sequence:
- Creditorpaymentactivationrequest (or pain.013) is a message sent from Bob to Alice
- CreditorPaymentactivationRequestStatusReport (pain.014) is the return message to Bob
The main advantage of a bill presentment system are:
- Bob can initiate the flow, which is useful if Bob is a retailer.
- There is an electronic flow (#2) that could help Bob to have information before receiving the funds that could come later (Day+1 in SEPA but many more days in other schemes)
- By automatically linking #1 and #3 flows, some errors (wrong IBAN of Bob,…) can be avoided
The main limitations are:
- How to send those 2 mew messages?
- using the Internet, but with which security measures?
- using an existing Clearing & Settlement system (CSM), but what about the limitation of the CSM, as batch processing?
- What is the period of validity of the first message? At what time Bob should consider that Alice will not answer to the request?
- What are the identifiers of Alice to receive those 2 new messages?
- IBAN of Alice, but how to protect this IBAN
- *at the Bob information system level
- *during the exchange
- Other identifier, and how to manage it
- Is the “creditorPaymentactivationRequestStatusReport” a signed message that could give reliable information
-
guarantee that the funds will be transferred
-
guarantee that is really Alice who send the message
-
Each bill presentment system addresses these issues, but different bill presentment systems do not interoperate; each defines its own rules.
-
Often those systems are dedicated to end of the month (or slow) payments, mainly by utilities.
-
The exchange mechanisms are often the CSM, and the batch operations are not an issue when dealing with utility company invoices.
-
Identifiers are IBAN or IBAN aliases to avoid direct debit fraud