Payment industry

In essence, credit transfers are extremely simple. In a minimal system, you need three parties: a credit provider, and two account holders. The first account holder simply instructs the credit provider that a part of the credit that he can draw from the credit provider should be transfered to the account of the other account holder – so that the other account holder can now draw more credit from the credit provider.

So, before:
Client A has been offered a credit of 2 units by the credit provider – and can draw that at any time
Client B has been offered a credit of 2 units by the credit provider – and can draw that at any time

Then, client A instructs to give one unit of his credit with the bank (credit provider) to client B

After:
Client A has been offered a credit of 1 unit by the credit provider – and can draw that at any time
Client B has been offered a credit of 3 units by the credit provider – and can draw that at any time

The credit provider is not part of the situation or reason that led to one account holder wanting to give away some of the credit that he has with the credit provider to another account holder. The agreement between a credit provider and an account holder is merely that the account holder has a right to draw (get delivery of) a pre-agreement amount of credit that the credit provider granted. This credit can be a loan or an advance, but it can also be an equal amount of money that the account holder previously handed over to the credit provider (so “his own money”) – which is basically the case with most consumer bank accounts. The difference between a credit provider and a custodian also lies here: a custodian keeps your assets and you have to right to get them back or to instruct that someone else gets them back – whereas a bank/credit provider became owner of your money and in return you receive a credit that allows you to claim the bank/credit provider’s money.

Consumer credit origination that is based on a deposit, are traditional bank accounts of deposit taking banks. Consumer credit origination that is based on loans and advances, are credit card, 2Bill,

 

In reality, the credit provider will be a bank. That can be a central bank – and in the situation described above, the two account holders will then for instance be commercial banks. It can also be a commercial bank with who consumers or companies have an account.

In a bit more complex system, you can have an account holder that wants to have some of the credit he has with credit provider A to be transferred to an account holder that has a relationship with credit provider B, but not with credit provider A. If you are lucky, then credit provider A and credit provider B are in their own right account holders of a credit provider C (for instance a central bank). So when the account holder instruct credit provider A, credit provider A can instruct credit provider C to move some of the credit he has with C to credit provider B that can then incraese the credit that he provides to the destination account holder.

In the real world, banks does not only provide credit to account holders, they also have credit themselves with various bank – central banks or just ordinary other banks (nationally and internationally) – and this makes international bank payments possible.

This whole system is possible in low or no tech situations. It is basically a matter of bookkeeping – namely keeping track of the amount of credit that has been granted to clients, and administering movements in that (based on withdrawals, or new deposits, new issuances of credit and the execution or reception of transfer instructions). The instructions to move credit or assets (in case of a custodian instead of a credit provider) were for instance possible in paper based format: take the case of cheques as an example.

Today, the instructions are inserted and received through information systems. Also the maintenance of accounts is managed through information systems. The process of having instructions ultimately result in changes in the accounts, is called clearing and settlement or often just one of those – and the reality is that there can go over quite some time between the time that an instruction is given/received and that it is ultimately reflected in the accounts. In fact, when the system is made up of several layers, that time is just multiplied as the central credit provider in every layer might need some time to process an instruction and have it reflected in the accounts of the two account holders involved. Such delay can be annoying as it means that it can take some time before a receiving party can use the credit himself. For that reason, there are sometimes regulations that limit the timeframe within which a payment instruction must be processed and reflected in the accounts of the two involved parties – and sometimes even the parties of a further layer.

Next follow some of these systems.

Target 2 is the system that is managed by the Eurosystem (central banks of the euro countries). It is an account management system and instruction processing system (thus basically an integrated settlement system) of about 20 central banks. Thus, if a commercial bank has an account with the central bank of France, then the account is basically a digital instance in the Target 2 system. Almost 1800 credit institutions in Europe have an account that is provided by a euro-participating central bank and that is digitally managed in the Target 2 computer system. The monetary amount of instructions last year (2016) that were sent to the system, amounted to €446 trillion.

Another example is Bankgirot in Sweden for Swedish Kroner, an average of over four million payments for a total value of approximately SEK 53 billion are cleared through the Bankgirot payment system each bank day. Such systems are not necessarily account management systems, but sometimes just instruction processing systems. Other examples are EURO1 (Europe), Fedwire (US), CHIPS (US), SIC (Switserland), EIS (China), CHATS (Hong Kong), ETG (Hong Kong), Gaitame (Japan), EFT (China), LCH (China), IBG & FAST (Singapore), BAHTNET (Thailand), CHAPS (UK), TBF (France), Bi-REL (Italy), ECH (Thailand), Zengin (Japan), Bacs & Faster Payments (Japan), FPS (UK), New Payments Platform (Australia).

The only privately owned and operated EU-wide payment system is the EURO 1 system of the Euro Banking Association (EBA). EURO 1 processes interbank payments as well as commercial payments.

Connecting to such an IT system does not happen via the internet. In most cases, connecting to those systems happens through the SWIFT network, and the format of the instruction messages if laid down in standards. One of these standards or ISO20022.

Standardizing the messaging format is a very powerful thing. For instance, in Europe a messaging format standard is SEPA – and applying this format straight from the instructing client’s bank up until the recipient’s bank allows straight through processing through the different systems that it travels (with the Target2 system centrally).

 

How to deal with the settlement delay?

Many things can cause a settlement delay. For instance, if an end-user’s instruction to his credit institution (bank) needs to be transformed into another instruction from his bank to the settlement system of the recipient’s bank, or perhaps even an in-between correspondent bank, then this might mean that banks first group a number of payments into one payment that they instruct to the respective settlement system. Because most settlement systems charge a fee per instruction, so bank have an interest to group the payment instructions that they send to such system. This groupage can cause a few hours or a day delay. Also, even the transformation of an end-creditor’s instruction to his bank instruction the settlement system to which it is connected, might need some time purely because not all sytems are automated. And then, even when all this has been taken care of, the updating of the records in the settlement system – thus informing the receiving bank of the increase in credit, might take time. And oh yes, not all settlement systems operate within the same time zones and cut-off times – so it might well be that an instruction that arrives at a settlement system will only be treated the next day. And it might also take time for the receiving bank to update the credit position of the ultimate recipient. The more layers between the payee and ultimate recipient, the more time that this chain accumulates.

To deal with this, some policymakers have put time limits on the time that a credit institution might spend between the reception of an instruction from its clients to the transformation / groupage into a bigger payment instruction to the settlement system that the bank is connected to. This is for instance the case in Europe, under the condition that the payee has formulated his instruction according to the SEPA format/standard.

Another system, is to inform the receiving bank / recipient that the payee has instructed his credit institution (bank) and that he had sufficient credit to effect the payment. Thus, that it is a matter of certainty that the instruction will be pushed further and will ultimately be settled. This is what happens with credit card payments, but also with debit card payments or with solutions like Sofort, Trustly, MyBank, etc.

MyBank is a product of Preta S.A.S. which is a subsidiary of EBA Clearing – the subsidiary of the European Banking Association.

Trustly is a Swedish company that allows that customers enter their banking authorization details in a safe environment, and then when the payment has succesfully be instructed, the recipient is informed that he can provide his service or good – as trustly from that moment on will make sure that the payment settles. Trustly allows this for payees with bank accoutns in Sweden, Norway, Finland, Denmark, Estonia, Poland, Italy, Spain or Malta.

Sofort applies a similar principles, and mainly allos payees that have a bank account in Germany, Austria, Belgium, Poland, Spain, The Netherlands, etc.

Many systems like that that operate on a national level also exist. Exampels are iDeal (The Netherlands), Giropay (Germany), POLi (Australia), Bancontact (Belgium), EPS (Austria), InstantBank (Estonia, Finland, Poland, Sweden), Transferencia Bradesco, eKonto, eNets (Singapore), Debito Bradesco, etc. Many of these systems are created on the basis of a cooperation among national banks, and they may operate as mutualized institutions, but they are sometimes also initiatives of an independent player. Many of these systems are also the systems that apply the system both for physical (debit or credit) card payments that are authorized by pin, as well as for online payments that are authorized through TAN, 3D-secure, temporary code, etc.

[smls id=”1781993″]

Many banks have recently also implemented systems where a merchant can be informed as soon as a payer has succesfully and irrevocable instructed a payment – and where settlement is thus merely a natural consequence. Examples are BankLink from Swedbank,

[smls id=”1783066″]

In a European context, such services that group a few banks are called Payment Information Services (PIS). PIS checks on a payee’s internet bank and informs merchant that

• They received confirmation of the payment instruction and
• The payee have funds to cover payment
• On this basis, merchant can go ahead

This is a concept that is introduced with the second payment services directive (PSD2). At the core of PSD2 is the requirement for banks to grant Third Party Providers (TPPs) access to a customer’s online account/payment services in a regulated and secure way.

This ‘Access to Account’ (XS2A) rule mandates banks or other account-holding Payment Services Providers to facilitate secure access via APIs to their customer accounts and data if the account holder provides consent. In order to provide this access to accounts, banks must also allow for customer identity verification and authentication via APIs. This will allow third-party payment initiation (PIS) as well as third-party account data aggregation (AIS). Thus, third parties will be able to initiate online payments to an e-merchant or other beneficiary directly from the payer’s bank account via an online portal. And third parties will be able to extract a customers account information data including transaction history and balances. This will most likely result in a loss of customer ‘ownership’ for banks in Europe.

 

Same system participation: real time settlement in the case of wallets

The above systems are very relevant when payer and recipient have accounts with different credit providers (banks). However, given the rise of the internet, a number of players have made it so trivial to open an account that it is now very easy for payer and recipient to have an account with the same institution. As a result, the instruction of the payment (credit transfer) and the information to the recipient can take place from the same account provider. The settlement can also take place immediately. This is the case of wallets like Paypal, Skrill, Neteller, Tenpay, Qiwi, Yandex.Money, Paga (Nigeria), etc.

[smls id=”1782014″]

Technically, wallet providers and banks (credit institutions) are both account providers. Legally, there is however often a distinction between the two. Depending on the country, the destinction might for instance be that a wallet provider rather acts as a custodian instead of a deposit taker, or other forms where the accounts are not a claim against the account provider.

 

Connectors

The above mentioned authorization systems that allow merchants to deliver goods and services even before payments are settled, are thus very handy. However, a problem arises for merchants with an international clientele. They need to connect to many systems. So parties have stepped in between that make a business out of connecting to many systems, and then in return only offering one single system to merchants that seek instant confirmation of payment instructions that will result in future settlements.

Examples of such companies are Pay.on, Paygate, Worldpay, Dotpay, etc

[smls id=”1782009″]