Skip to content

Home

Jump to bottom
Cyril VIGNET edited this page Sep 5, 2017 · 36 revisions

The credit transfer paradigm

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:

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 scheme 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.

Corespondent Banking

The corespondent banking is a generic term for a hudge number of bilateral agreements between banks in order ot provide Credit Transfer from almost any banks in the world to any banks. So far, it is not exactly a scheme because rules are not always the same: they depend of each bilateral agreement. As it is quite impossible for a bank to manage bilateral agreements with ALL the banks of the planet, a credit transfer could spring from different banks before reaching the ultimate target. This lead to a feeling of no transparency of the system. Technically those bilateral agreement use the SWIFT network but it could also be other networks or direct connections.

Faster Payment

Instant Payment used in UK.

Credit Transfer versus Payment

In our view a payment is a mechanism that links a purchase (done by Alice from Bob the retailer) with the transfer of funds between the account of Alice and the account of Bob.

The Credit Transfer could be used to pay purchases but also to manage accounts (cash management). As the credit transfer is not specifically designed to make payment (unlike a card system wich is design specifically to do payement), other additional mechanism help to do that.

The bill presentment

Flows of the Bill presentment mechanism with Credit Transfer

The bill presentment is an enhanced cinematic with a set of messages that provide a mechanism to exchange data (identifiers/amount/information) before the credit transfer.

Two additional flows are defined before the credit transfer in the sequence:

  1. Creditorpaymentactivationrequest (or pain.013) is a message sent from Bob to Alice
  2. CreditorPaymentactivationRequestStatusReport (pain.014) is the return message to Bob

Advantages of Bill Presentment

The main advantage of a bill presentment system:

  • Bob could be at the beginning of the sequence, 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,…) could be avoided

Limitations of bill presentment systems

The main limitations are:

  1. 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
  1. What is the period of validity of the first message? At what time Bob should consider that Alice will not answer to the request?
  2. 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
  1. 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

  • All those limitations are addressed depending of the each bill presentment system which defines they own rules (they are not interoperable)

  • 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 utilities invoices.

  • Identifiers are IBAN or alias of IBAN to avoid direct debit fraud

Clone this wiki locally