Helping PayID and NPP Fight Payment Scams More Effectively
Let’s dive in why PayID is not a replacement for proper Confirmation of Payee as long as payments to bank account numbers are allowed.
With countries like the UK, Singapore, Japan, the Netherlands and France adopting “Confirmation of Payee (CoP)” as an effective global anti-payment-scam mechanism, there seems to be a debate on whether or not Australia should deem PayID as ‘some sort of Confirmation of Payee (CoP)’ and whether or not banks should take an action to implement Confirmation of Payee. Obviously, the ACCC has been urging banks to actually do implement CoP.
Payee-Auth.com.au is proud to provide international & domestic privacy-preserving zero-knowledge Confirmation of Payee to the banking world without banks having to share any customer data or having to change existing payment systems integrations/rails or having to establish data sharing treaties with other banks or countries or having to spend big money. Our goal is to eradicate payment fraud ‘categorically’.
Australia’s New Payment Platform (NPP) and PayID are the result of years of hard work and investments and are already adding a great deal of value to all Australians. However, there may be areas that PayID and NPP can be strengthened even more to fill the remaining gaps and to become even better.
We like to dig in a bit and provide insights on where PayID can become a stronger tool against payment fraud and scam with Payee-Auth’s incremental value to it.
So let’s dig in….
What is PayID?
PayID comes from an ISO20022 concept for ‘account aliasing’ (as opposed to ‘account holder’s name aliasing’). “An account alias is reference data such as a mobile number or electronic address that can be used to look up the account information for a debtor or creditor”.
The philosophy is to try to refrain from having to share bank account numbers (e.g. RTN, BSB, Sort Code plus account numbers) and instead, use an alias people are more comfortable sharing and are much more likely to have confirmed before, like their email address, phone number or an identifier of a business (e.g. the ABN (Australian Business Number) of a business).
Observation 1: PayID as an Alias for Account Details vs. an Alias for Private Personal Details
While ISO20022 does not fully mandate or restrict options around account aliases, the implied concept here is to use an account alias to look up the original physical “account”, as opposed to looking up the private personal details of an “account holder”. The European payment wallet Swish is an example platform making it possible to pay someone using a phone number. Zelle and the Cash App are other examples.
In its current incarnation, a PayID, especially for personal payees, maps to their full name which makes PayID do a bit more than the intended use of an account alias.
This issue has been already discussed by reporters in their stories that PayID leaks the mapping of names to phone numbers or email addresses. There have been cases of personal information breaches on top of PayID as well.
Openly leaking private information is not a good practice and may have been an unwanted outcome here but in hindsight, it can be argued that the intended use-case of account aliases may have been to allow an account alias to map to the physical account details (e.g. BSB/Account Number) rather than the name of the account holder.
We see this as an important point to highlight the “flow of information disclosure consent” in a payment process. So, a payee consents to providing their details to a payer to get paid by them; the payer then discloses the details to their bank at the time of payment, the bank then facilitates the payment and if they were able to verify them, the preference would be to do so, and if the bank had a way to keep the disclosed information private, the bank would logically take that option. There is a state of equilibrium in this flow since the disclosure of information is all under consent and private, not public. In the current PayID implementation, however, there is an implied consent that a PayID owner’s private details hereby become possible to be looked up by everyone using their phone number or email address which may be too wide of an opening.
Conclusion: Confirmation of Payee is still a hard nut to crack as it includes cross-organizational verification of private information. While account aliases can be reframed to do more than what they were intended to do by returning the name of an account holder, they may not replicate the protection that Confirmation of Payee brings without having to seek everyone’s consent to publicise their private details or opt in.
Observation 2: Unverifiable BSB/Accounts Are a Permanent Pathway for Fraud, Irrespective of PayID’s Effect
To prevent scam, one must think how a scammer operates. Eliminating options used by scammers may go a much further way than providing new options to legitimate payers and payees.
In other words, the options that are available to scammers matter much more than the options that are available to legitimate payers and payees.
Imagine that one is a law-abiding citizen/biller and have signed up with a PayID and are including PayID as their payment method on their outgoing invoices.
Any scammer can still send out invoices on that party’s behalf by compromising their email with scammer-controlled BSB/Account details and ‘the legitimate payee’s name’ on the invoice; replacing the original PayID as the payment method on the invoice.
As long as it is possible to pay someone using BSB/Account without CoP for all, it will be possible for scammers to do what they do unless invoices get digitally signed to become tamper-proof.
Our award-winning sister venture Xiippy.ai provides tamper-proof digitally-signed end-to-end encrypted private invoicing to its clients. These invoices become available within the secure zero-knowledge Xiippy dashboard and are not emailed. The platform includes a step to verify the invoice is coming from the right party and that its contents have not been tampered with.
In lack of CoP for BSB/Acc payments, digitally-signed invoicing may be one of the best bets available as a “biller” to protect yourself and your customers.
Conclusion: Even if all the country had PayIDs today, CoP would be still necessary as long as BSB/Account payments are available as a payment option. PayID’s existence is not replacing the original need. In fact, having CoP helps PayID’s effectiveness increase significantly because PayID is still a minimal-entry payment option, as opposed to a full direct-entry option like BSB/Account empowered by CoP.
Observation 3: Automated Payments Will Take Long to Transition to PayID
Many HR and accounting systems come with existing integrations and features to generate batch payment files. Many business-focused banks also support importing and processing such batch payments through their Internet banking systems and applications.
Without these two groups of systems transitioning to support PayID, NPP and more contemporary ways to identify a payee, “how many people” or “what portion of the population” are using PayID may be an incomplete stat to look into.
As far as individual payers and payees go, getting a PayID is easy provided the consent and data sharing implications are all OK; it is such systems and integrations that are hard to modify and will take long.
Conclusion: Still implementing CoP at banks level is the fastest and shortest way to global immunity against many common payment scams. Encouraging payees to sign up with PayID while BSB/Account payments will keep getting used by automated payment systems will always leave the door open for BSB/Account payments to be abused by scammers unless BSB/Account payments become part of history over time.
Observation 4: Small Fast Payment Quotas and Limits
Most banks have a small daily limit applied to fast payments. These small limits make PayID a suitable payment method when you want to pay your split bill on a dinner table but not for those payments that are the main target of scams (e.g. real-estate deposits which may be easily over $50k).
In real-estate deals, agents normally expect to receive deposits quickly and in one chunk, not over a 10-day period, 5k on each day.
This is another reason why Australia’s classic “Pay Anyone” pathway for direct deposit payments using BSB/Account is much more relevant for the types of payments that are the target of payment redirection fraud. No scammer would bother trying to redirect the $22.57 payment which is your share of your lunch with your friend who needs to be paid.
Conclusion: To make PayID more effective and widely-used, fast payments’ daily quotas and limits should be increased, even though it may make cancelling payments much harder (after all, slow payments may give the payer an option to stop the payment if it is still in the queue!)
Observation 5: Mule PayIDs; Still a Possibility
Once again, to build a better system, one needs to think of what scammers do.
Some scammers open a mule account under stolen identities which they will then empty after a successful run of scams.
It could still be possible for someone to register a business name or entity with close-enough spelling (missing a vowel here or there, e.g. ‘ABC Conveyencing’) using fake stolen identities and get a bank account and a PayID for the business name or mule entity and put that on a fake invoice.
This is an extreme case but it is very hard to pin point and prevent. If that happens, then a poor over-trusting senior citizen may simply get a boost in confidence that ‘everyone says PayID is secure. It is great that the invoice uses it too. Let’s pay then’, unaware of the fact that the money is still being redirected to an unauthorized payee.
TIP: It may well be necessary to call and ask even if an invoice with a PayID is being paid! It is annoying, but may be still necessary.
The psychology of a payer who is about to make a large-sum payment is interesting. This whole desire to refrain from direct entry may not be a good thing for large-sum payments after all. There are merits in having to enter the full details only when such details get verified. This gives the payer the confidence that their money is safe if there are issues with the details and that confidence is worth the effort one has to put down in order to type the full details.
Conclusion: Just like what Payee-Auth does, payees’ account meta-data and trust indexes can be externalized to a payer which helps them identify mule account risks. PayID alone may not be able to fight these scenarios. A proper Confirmation of Payee may make PayID a lot more secure and complete compared to its current state, which is what Payee-Auth.com.au does.
Now What?
‘Confirmation of Payee’ is known to be a hard nut to crack.
There was a time implementing Confirmation of Payee required the followings:
· Establishing data-sharing treaties between banks (or countries)
· Convincing banks of sharing customer data (which is deemed a bigger risk than not having CoP in the first place)
· Seeking the opt-in and consent of each account holder (like what PayID depends on)
· Exposing sensitive publicly-available APIs or making changes to sensitive payment systems integrations
· Create consensus between competitors on something
That time is now gone!
Payee-Auth’s innovative method of providing Confirmation of Payee has resolved all these barriers, without any exception. We have paved the way for CoP to become available while maintaining 99% of the current state. That 1% is the effort a bank should put down to
· Built a Virtual Machine and run Payee-Auth’s PII Certificate generation tools against account name and numbers
· Build a light-wright UI integration to confirm payees’ details before the payment is made and to also make the trust indexes of the account known to the payer
And that’s it. No private data ever leaves the premises of a bank with Payee-Auth’s innovative technology.
Any bank can now protect their payers and payees within as little as 1 week’s worth of effort. What is left then?
Feel free to reach out to “Contact [ATSign] Payee-Auth.com.au” so we can help you protect your customers as both payers and payees.
