Third to first - join the party
Changing from third to first is changing up. And here’s an easy way to do it
While there’s nothing essentially wrong with third-party payments, their unpopularity with many banks can cause considerable delays to international payments. Sometimes they can be blocked completely. The reason is simple: ignorance isn’t bliss; it’s risk.
It’s axiomatic to financial compliance that every institution is responsible for its own process. When accepting a third-party payment, you’re effectively trusting that your predecessor(s) in the payment chain did their job properly. If something goes wrong, like a dishonoured payment or a compliance infringement, at best you’re faced with a complicated process to prove your innocence. At worst, you could be facing penalties or even prosecution. Even if everything’s as it should be, a single request for information slows everything down and soaks up resource.
Typical fraud schemes made easier by third-party payments
Let’s take an example. A financial institution onboards a construction materials company, examining documentation such as incorporation and share certificates, identity proofs for company officers and so on. Having completed its diligence, it approves the new customer for transactions of up to a million dollars. The following week, a payment instruction is received, for bricks to be imported from India. The transaction value is $680,000, well within the account limit, so the transfer begins. Settlement is required in rupees, for which the institution has no account, so it passes the payment to a partner. This organisation operates a trust model, so it makes the conversion and sends the funds onwards to the receiving bank in India.
If all parties were members of SWIFT, the payment details were probably passed along via MT messaging. If not, then it could have been any mix of APIs, spreadsheets and emails. Whatever means was used, it’s highly possible that the only information was:
Originator: Webild Construction Inc
Beneficiary: Empire Clay Ltd.
Value: 58127420
Currency: INR
Purpose: Building materials
This might be enough for the receiving bank; after all, it onboarded Empire Clay, and would expect payments of this scale for goods of this type. The fact that $680,000 changed hands for $10,000 worth of bricks escaped everyone’s notice - until the regulators spot it and everyone’s in big trouble.
In practice, it’s likely that one of the subordinate organisations will hold the payment while they request further information (RFI). A couple of days later, they receive a copy invoice (this time let’s say it checks out), and pass the payment on. And the next organisation sends back a further request. The delays and cost mount and, when the settlement finally lands, it’s still a third-party payment .
The next transaction from the same company undergoes exactly the same process; it was never a customer of the intermediaries, so the RFIs flow once again. Moreover, all of this depends on the willingness of every counterparty being willing, as a matter of policy, to process third-party payments - and it’s easy to see why a growing number of financial institutions are ruling against them.
So what’s the answer?
What we need is a way to process in partnership with other organisations, but maintain every transaction as a first-party payment. That may sound like a big ask, but it’s easier than you might think. It all comes down to efficient communication. Much of this website extolls the virtues of the eKeyiD, and here we go again…
How the information flows
In the diagram, the initiating institution onboards its customer as usual by collecting information and documents. But instead of storing this data internally, it’s uploaded to a private node of our ultra-secure federated ledger vault (many of our users allow their customer to do this, reducing workload and making the customer feel more involved in the process).
Our system encrypts and secures the data and generates an eKeyId. This is a short identifier that can be shared freely without compromising privacy.
The eKeyiD can now be passed along the chain by any preferred method - SWIFT, Fedwire, API or specialised platforms. It’s sufficiently compact to fit within even the most restrictive messaging systems.
The next institution in the chain receives the instruction, with the eKeyiD included. It can now request permission to access the documents held in the vault. They can now view the full onboarding material and make an informed decision on onboarding the customer. This access is permanent and can be referred to for any inspection or audit trail.
When the instruction is passed along the chain, the eKeyiD accompanies it. Each ensuing institution can then make its own onboarding decision and pass on to the next party.
You can see how we balance privacy and transparency (PvT) in this post.
Ensuing transactions
Each payment carries its own eKeyiD, which will contain full information about the transaction - invoices, bills of lading etc. - along with the original documentation gathered at onboarding (suitably updated to accommodate expiry of passports or licences). Processing is simply a matter of rechecking the data and passing the instruction along.
As the customer has been onboarded and approved by every party, the payment remains first-party all along to its destination. The only change to existing methods has been to simplify them, yet at a single stroke, we’ve cleared a massive barrier to acceptance of cross-border payments.
A self-healing information chain
The diagram shows how information can flow where all parties are connected to the CertiQi platform. But what happens if one of the intermediaries isn’t a member? Does the whole structure collapse? As long as each party passes along the information it receives in the payment instruction, including the eKeyiD, then the chain self-heals and the full information stack jumps the gap to become fully visible.