Skip to content

Home

Jump to bottom
ianbjacobs edited this page Sep 7, 2017 · 36 revisions

The Credit Transfer Paradigm

Introduction

This wiki introduces key elements of using Credit Transfer to move funds.

Terminology

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.

Nominal flows of the Credit Transfer

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:

  1. The originator initiates the credit transfer at 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 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.

Initiation of the credit transfer by the originator

  1. 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)
  2. 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:

  1. : Bank A has received the file (if done by file, obviously)
  2. : Bank A is able to read the records in the file
  3. : Bank A is able to process the record : the account (of Alice) has enough money
  4. : The credit transfer has been sent and pay through the CSM (clearing and settlement mechanism)

Interbank credit transfer

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.

Notification to Bob

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

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