When I first launched this series, the idea was to break down the world of moving money and making payments into a series of practical and easy to follow guides. Over four parts, we covered the essentials: how money moves, is settled between institutions, crosses borders and then facilities the trade in securities.
But a lot has changed since then, particularly the widespread adoption of multicurrency accounts to manage payments and reduce FX costs. So in this article we are going to cover how these products work and some of the complexities that arise, particularly if you are trying to 'follow the money' through these accounts.
Making a payment to someone in a different currency is a modern form of alchemy. Instead of converting base metals into gold we are converting debt expressed in one set of units belonging to one system to debt expressed in another. It's quite magical. If I want to send British Pounds and I want my counterpart to receive Euros how can this happen? Where do my pounds go and where do the Euros come from? The simple mental model of sending physical cash in an envelope from sender to recipient breaks down.
In Part 3 of this series we looked at how Correspondent banking solves this problem by using a chain of banks who each agree to owe each other a little bit less, or a little bit more, in a specific currency to achieve an end-to-end transfer. At at least one point along the chain (usually the start or the end) one bank agrees to perform the currency swap, ending up with less of an obligation in one currency and more of another. This process is slow, complicated and costly for the end user. Each transaction is dealt with one at a time, at the prevailing exchange rate with additional fees along the way. For one-off transactions this maybe acceptable but if you are regularly seeking to make and receive payments in different currencies this becomes very expensive and unpredictable - there has to be a better way! Enter multi-currency accounts.
What if I could hold an account with each currency I need to work with and move money between them as I need to? This sounds great, but how is this alchemy to be achieved? As with many things in the world of the payments the solution is, like the concept of a bank account itself, a façade with some clever abstraction behind the scenes.
As mentioned above, debt (or money) is expressed as a quantity of a certain unit that is owed at any one time. As such an account, i.e. a record of a debt, is by definition linked to a single currency. As we saw in Part 1 each currency has mechanisms (often called payment systems or payment rails) to swap these debts from one holder to another. This is how money 'moves', along these pre-defined rails. But this transfer mechanism is essentially a closed system, it's swapping Pounds for Pounds or Euros for Euros.
Proxy Accounts
So a single multi-currency account is really a set of debt obligations in different currencies that are grouped together for the convenience of the customer. Unlike traditional single currency accounts, these logical balances are often not directly addressable via the currency's payment platforms. They typically are not able send or receive money in their own right and their account numbers are not valid payment identifiers.
Payments to multi-currency portfolios are often sent to shared payment-on-behalf-of (or POBO) accounts, together with a reference number to identify the intended beneficiary. The addressable funds (i.e. the monies in the directly accessible single currency account) are aggregated together and maybe used to make outgoing payments, on behalf of different customers. The balance the customer sees against a currency in their multi-currency account, is a simply record of their claim to be able to make payments in that currency, up to the value they hold, at some future date. While this is to some degree true for a conventional bank account, with a virtual multi-currency ledger the customer is one step further removed from actionable funds with which payments can be made.
Multi-currency account providers offer the ability for their customers to convert or swap their funds from one currency to another, at competitive wholesale exchange rates. Behind their flashy user interface this transfer is a simple ledger swap within the provider's internal accounts; they agree to owe their customer a few more pounds and few less euros. No transactions are recorded on external currency payment systems, no currency is created or destroyed, the promises to pay in each currency are simply adjusted.
This virtualised arrangement works well with the multi-currency provider making wholesale adjustments behind the scenes to ensure they always execute their customers' instructions and have sufficient directly addressable currency available to make payments. Because these payments can usually be made directly via the local currency payment rails they can be conducted a lower cost than executing through a chain of correspondent banks.
Whilst efficient for customers these virtual multi-currency accounts make the process of investigating money transfers significantly more difficult. The lack of consistent and individually unique account identifiers makes it harder to trace the flow of funds associated with an individual into, through and out of their basket of different currencies.
For example imagine a customer holding a multi-currency account with balances in Euros and US Dollars.
Firstly, they wish to accept a payment in Euros and so ask their provider for Euro payment details that they can relay to their payer. The provider instructs them to use the shared account number DE89 3704 0044 0532 0130 00 with reference 12345. They provide these details to their payer. Once the transaction completes, via Euro SEPA payment rails, the equivalent funds show as available on the customer's currency portfolio.
Next, the customer instructs their provider to convert these Euros to US dollars. This internal ledger swap proceeds and the balance of available Euros is decreased and their US dollar balance increased.
Finally, the customer then issues a further instruction to pay these newly available US dollars to a US third party. The multi-currency provider executes this instruction, via a US institution, by sending an ACH payment instruction from its aggregate US dollar account, with account number 001234567890. Let's now consider how this disconnect in the funds flow introduces challenges in following the money.
Let's imagine the original payer, from whom the funds initiated, is identified by their bank as suspicious. The recipient of the original transfer, our multi-currency account holder, now comes under scrutiny as does the account number on the transaction, DE89 3704 0044 0532 0130 00.
As part of their investigation the originating institution will wish to establish whether any other transfers to that account have been made from other customers, who by affiliation could also be suspicious. But wait, that account number is not specific to our multi-currency account holder, as it is a shared account. This means that investigative tools based on account numbers only will potentially show an incorrect network of associations between unrelated customers. The same confusion may also occur when tracing other recipients of transfers from a suspected outbound POBO account, this time often without the benefit of a customer-specific reference to ensure the funds reach the right destination.
For the multi-currency account providers the detection of the rapid passthrough of funds across currencies becomes more challenging as there is a need to correlate the amounts and timestamps on incoming, internal ledger conversion and outgoing transactions to identify suspicious behaviour.
For the financial institutions hosting POBO accounts and facilitating connections to local payment rails, the ability to identify deviations from expected behaviour is rendered more complex as payments to and from a variety of customers are mixed together as a shared funds. As a result these composite accounts present similar risks to those associated with correspondent accounts.
In conclusion the added layer of abstraction has simplified and enhanced the end customer experience, reducing end user friction and cost, but has also further obfuscating financial transparency and made the job of detecting and investigating financial crime that much harder.
In the next part of this series I will take a look at a special type of virtual account - a virtual Iban that is often used in conjunction with multi-currency accounts.