Payments Information in the Real World: Peering through a Broken Text File

Thomas Barker gives a special insight into the world of payments in an online world.

This article is not about law or the legal aspects of anti-money laundering. It is not about jurisdiction. It is about the real-life plumbing under those formalities, and the quirks that drive gaps between what is meant to happen, and what actually happens, in payments back offices. I hope that this will equip the legal reader with some sympathy for the front-line staff who might appear to be forever falling over some small inconsistency or other!

The author has experience integrating to multiple banks across several non-financials. This article also draws on many others experience of handling payments from major banks. Issues outlined below draw on specific cases, but these issues are caused by the age of current core banking systems and the limitations of current payment networks. The issues are systemic, rather than around certain institutions.  

Some definitions 

Nostro accounts: Normal bank accounts are vostro accounts - they are held in the name of the beneficiary who also controls the account. Nostro accounts contain monies which are held for third parties. So a currency transfer service's accounts would be nostro accounts as they are held and managed on behalf of that service's clients.

Correspondent banking: Clearing arrangements between two banks to handle payments for one another. Often this involves the creation of nostro accounts.

Intermediary: For our purposes, any organisation that facilitates or accepts payments for money that is not its own. Banks are often intermediaries.

Non-financials: Organisations providing a service which involves handling client money which is not a bank. Non-financials are intermediaries for our purposes.

Client money account: The name by which non-banks usually refer to a nostro account for their client's money.

Payments network: For our purposes, a communications system to arrange payments and exchange information. Does not include clearing.

Payments platform: For our purposes, an integrated payments network with centrally administered clearing. These are usually national in scope and organised by a central bank.

Introduction 

Current banking IT creates issues for non-financials (currency dealers, transfer services, stock dealers, etc) in effectively tracking client money and fulfilling their statutory AML obligations. Overall non-financials are coping with these challenges, but gaps in information handling within the banking system create a substantial extra workload. And with those costs comes the risk of mistakes that might let small-scale money laundering slip through unnoticed. The situation will be significantly worse amongst small intermediaries, high-value dealers, estate agents and law firms - who often handle large transactions but lack the institutional knowledge and internal processes of high-volume non-financials.

Regulators have made great strides over the last decade to force improvements in the level of information attached to payments, especially across the SWIFT inter-bank messaging system. These improvements are sadly often futile as the information added might never manage to leave the payment network - and because current payment networks cope badly with a financial ecosystem in which non-financials play critical and varied intermediary roles.

As an example, let us consider a payment by an American citizen banking with a credit union in Texas to a British fund manager holding a US client money account. This payment might easily pass through: a Texas credit union, the credit union's intermediary bank which provides them with access to the US ACH transfer system, a major New York-based bank and the fund manager's London bank who have arranged the client money account. Ideally the payment would arrive with the fund manager's client services team with a detailed itinerary of its travels, full contact details for each intermediary's payments team, as well as the necessary full legal name, address, US tax payer identification number and date of birth for the fund manager's own know-your-customer procedure. Clearly, this does not happen. Under the above circumstances, most payments teams would be happy to find the surname and initials of the original sender still attached. I will examine the gaps that cause these issues. This article may well read like a long whine (which it is), but these issues create real differences between policy/legal intentions and what is actually practical in the global banking system today.

Value transfers are often not 'one shot' payments 

Money is moved in response to an underlying business relationship and rarely unconditionally. Payments are a process and typically involve multiple parties taking actions, often over several business days. Payment networks generally represent this poorly - usually they rarely accommodate the notion of a payment existing as anything other than a single message at all.

For example, in the case of most non-financials, a transfer from the client's personal bank account to the provider's client money account will not actually result in a transfer of value between two legal entities. The client has sole title to the monies at the start and end of the transfer regardless of who is holding it for them. Ownership-wise, the client is simply performing an internal transfer, as you might between a current and savings account. What can however often happen is that money is introduced from a source which is not (or appears not to be) the client's. The non-financial may also doubt that the original account owner correctly identified themselves. Obviously return of the client's deposited funds then has to be subject to further checks.

Escrow transactions are another common, uncovered case. These could be easily represented in any system were payments to be persistent over time and multiple approvals were possible. (There is some limited support in the SWIFT ISO20022 messaging standard, but this is simply not available at the retail level.)

Also problematic is the fact that for many payment types, the initial advisement of an incoming payment, the receipt of cleared funds and finalisation may all happen days apart. It is common for a receiver to be advised of an international wire several days in advance of it being credited to their account. And in some cases a sender can revoke a payment up to 60 days after it has been sent! (UK direct debits can be revoked after 5 years!)

Turn left at Citigroup and head for Barclays 

In 2013, HSBC was handed a record $1.3bn money laundering fine. Some of this was due to the behaviour of the bank's Mexican branch, but much of it was due to a process called 'stripping'. Non-US HSBC subsidiaries would accept payments from Iran (amongst other US sanctioned entities), substitute the Iranian bank and end-client details with their own, and then send the payment through to the US banking system for clearing. Stripped of any markers indicating its origin, US banks would then obliviously clear the transactions. Sadly, I would suspect the main reason that this practice continued unnoticed for so long is that the banking system so often accidentally strips details from payments anyway.

National level payments platforms generally presume that intermediary banks do not exist. This is untrue. In the UK, Channel Island banks usually send payments via mainland UK banks. This is also common for small county banks in the US. If the payments network allows only for direct transfers between the customers of two member banks, information that is attached to a payment must become a mixture of the sender and their local bank. This mixing is necessary as the receiver must be made aware of the intermediary bank to correctly send a return payment. (The US BillPay system is particularly unpleasant in this regard.)

Even with international wires [SWIFT], where the use of intermediaries is normal and expected, usually only one such intermediary's details can be attached to the payment. And often the receiving bank's own information systems will struggle to pass on even a single intermediary's information. In areas with a regionally focused banking system (such as the Democratic Republic of the Congo, the Middle East or the USA) multiple intermediaries are often necessary, eg one regional to national, one national to international.

Intermediaries, intermediaries everywhere 

Banks are not the only providers of unrestricted payment accounts. Brokerage houses often allow their clients to send payments directly to and from their accounts. Foreign exchange providers also need to allow clients to make payments to arbitrary accounts. With the spread of mobile money, even some telecoms operators have started to act as banks. Acting as a bank will however not grant an organisation first-class access to the necessary payment networks. Without a national level branch number - or for SWIFT payments an organisational BIC code - such payment providers have to be addressed via their clearing bank. So rather than a payment being made to 'MR T C/O INTERTRAXX BROKERS' it will be made to 'ACC:45986745 INTERTRAXX BROKERS C/O BIG BANK'. The payment network will not allow us to address the individual client money 'pot' within a client money account, so we have to make that distinction using magic codes in the payment reference. These problems can be alleviated by agency banking agreements, where a clearing bank will 'rent' a branch or organisation code to a large institutional client. That institution can then act as if it were a branch office of that bank. Sadly such agreements are expensive and rare. 

Banks themselves are not necessarily unitary organisations - traditionally in the UK each high street location would have its own branch identifier. Your payment would be sent to and from your home branch. Some banks still use this system, others have consolidated to their head office branch code, others use different branches for inbound and outbound payments and some use multiple branch codes interchangeably! This is not particularly problematic but serves to illustrate that behind a single bank brand lies a structure of actual organisational units. Payment identifiers are aligned to these functional structures rather than to a bank brand or legal forms. 

So, for example, banks might divert suspicious transfers to an internal investigations account and then have the compliance department make an onward payment if the transaction is approved. (How else to have a central AML function in a global group with multiple operational systems?) The payment will then appear to come from the compliance office! A global bank might have absorbed a local bank and then use the absorbed bank to route all of their payments for that country. Banks often hold nostro accounts with one another to provide access to local payment networks. And so forth. A global bank formed by mergers is typically a dozen separate function units. Short-term attempts to rationalise such banks can introduce even more intermediary entities.

Bank assumptions on required information 

Modern banks are very large organisations. (Citigroup employs 1/4 of a million people!) They have a huge base of legacy systems and the risk of replacing such systems is significant. A two-working day outage to replace the core banking system of a UK big-six bank would never be acceptable. It would cause hundreds of businesses to fail. So it is understandable that banks have very high costs in modifying or extending their IT offerings.

And banks have a lot of staff. A lot of staff. They tend to assume that other firms do as well. Unfortunately this leads to a strong bias towards manual processes with phone call enquiries and faxes. Banks also presume that their customers are largely indifferent to the origin of their payments. (Indeed most are.)

These pressures tend to lead banks towards semi-manual working processes. This is fine for the overwhelming majority of their customers who have business or personal accounts, but it means that intermediaries rarely receive the information they need through normal online banking channels.

As an interesting side-effect, it also means most consumers have no idea how much information is sent along with their payments. All they see when they receive a payment is a line on a statement and they expect the same to be true for everyone. Consumers are usually very surprised to learn that sending a CHAPS transfer gives the beneficiary their home address!

Banking Technology vs. Modern Best Practice 

Despite everything written about intermediaries and payment networks above, the major issue for intermediaries relying on bank payment information today are the banks information systems themselves. Typically these date from the 1980s (or earlier). As such, they pre-date current anti-money laundering legislation and the rapid growth of non-bank intermediaries. That means that information that was not required 20 years ago will often follow a different path through separate newer systems; flowing around, rather than into, the core banking system. Key details may arrive late, not at all - or only be available by phone/fax. Some banks may leave detailed payment records with the payments platform rather than extend their own databases to store it.

Machine readable payments reports often suffer a number of common problems. They were typically designed to deal with a single national payments type, so the additional information from more modern payment methods has to be retro-fitted to an older existing record structure. Modern payment methods allow for long text strings and international characters, but online banking platforms fail to support them. Truncation, particularly of names, is commonplace.

Sanctions screening can often cause problems since these systems are often very sensitive to, for example, the mere mention of a country name or variant, and may cause false positives to be internally re-routed at the receiving bank. As previously discussed, these routings can affect the availability of information needed by the recipient to make their own determinations.

Payments that are cleared within a bank between its own customers can often arrive with less information, since the internal transfer systems can be very old!

Some progress 

Even with the constraints commercial banking IT works under, there have been meaningful modernisation efforts across the sector. The ISO20022 standards that have come to the SWIFT payments network look promising. ISO20022 has a well thought out data dictionary and can pass details like date of birth and passport number cleanly between institutions.

Reference data files are available (at a price) for most payments platforms and networks. There are several firms that produce 'maps' of global correspondent banking relationships on a commercial basis. These can be very useful to high volume institutions which can justify their cost.

Despite having painted a bleak picture, the situation is not critical. The majority of payments sent today do have adequate information for both anti-money laundering and operational purposes. High volume non-financials have the operational experience to interpret the information they do receive and take action to fill gaps. It does however add a significant operating expense and represents a barrier to entry for new firms.

Questions for regulators 

The gap between the information pushed into payments systems and that which banks are able to pass onto their clients or process should raise questions for regulators. Many regulations have been stipulating the details that are sent with payments, but it is simply assumed that this information will flow downstream to the entities that need it. If this information does not flow smoothly, this affects the benefits, costs and risks imposed by these regulations.

It should also be considered that in some cases, such as consumer payments, the effort of collecting these details and consumer concerns about their use, may reduce the use of bank payments and/or shift these transactions to less controlled environments. Given that a few thousand euros can be sent in an envelope, is it worthwhile to rigidly control bank payments for a few hundred?

A significant source of the issues described stem from non-bank intermediaries' inability to join payment networks as 'first-class' members with their institutional identifiers and direct access to data. Any regulations which make this harder should be reviewed. Restricting such access to banks renders payment networks opaque (and harms competition).

As previously stated, I am not concerned that these issues make non-financials likely conduits for money laundering. There will be exceptions, particularly offshore, but mainstream non-financials are subject to strong regulation and are careful to comply. Intermediaries who handle small numbers of transactions in the course of some other business (such as estate agents, lawyers, etc.) should be a greater area of concern. They are unlikely to have the required resources or skills to determine that they are taking money from the right place.

Perhaps there is a regulatory grand bargain to be struck here. Currently, obtaining banking facilities is one of the largest challenges in establishing a new non-financial. (Particularly for those with novel business models.) Banks are understandably reluctant to offer client money accounts over which they have little direct insight. Perhaps, if banks could shift regulatory liability for such accounts on condition that they are able to provide timely accurate payments data to their non-financial clients, they would be more willing to extend these facilities?

At the very least data quality issues in the banking system should be surveyed. 

Thomas Barker is a software developer with a background in retail finance and peer-to-peer lending who concessionally writes on the web. He is currently hiding offshore from the UK banking system and will be back in London to work next tax year. His website is https://thomasbarker.com.

 

Further Reading

 

Compliance rules for the content of the 50A SWIFT field

http://www.swift.com/assets/swift_com/documents/about_swift/PMPG_FATF_SR_VII_v1_8.pdf

 

Correspondent banking explained

http://gendal.me/2013/11/24/a-simple-explanation-of-how-money-moves-around-the-banking-system/

 

HSBC's AML problems

http://www.rollingstone.com/politics/news/gangster-bankers-too-big-to-jail-20130214

 

ISO20022 for Dummies

http://www.sepahungary.hu/uploads/ISO20022_fordummies.pdf

 

Ross Anderson, 'Closing the Phishing Hole – Fraud, Risk and Nonbanks'

http://www.cl.cam.ac.uk/~rja14/Papers/nonbanks.pdf

 

Deutche Bank complaining about the same issues

https://www.ice.gov/doclib/aml/pdf/2009/levenberg.pdf

 

The US FinCENT agency report

http://www.fincen.gov/news_room/rp/files/CBFTFS_Complete.pdf

 

The BIS Committee on Payment and Settlement Systems publishes Red Books outlining the payments environments of its member states

http://www.bis.org/list/cpmi/tid_58/

 

Published: 2015-01-19T15:22:32

    0 comments

      This site uses cookies. By using the site you agree to our use of cookies as set out in our Privacy Policy.

      Please wait...