Community

We need to makes sure digital wallets can access the same functionality as that accessed by Apple and Google in their iOS and Android device OS respectively. 

I think some of the commentary in here shows a lack of understand of privacy and the challenges. It also shows a lack of understanding on how you can deliver trust without compromising on privacy. It's a grave concern that we still do not understand the importance of digital privacy, without it we are all exposed to a host of issues.

I think all of us in FinTech has known for years that Apple creates a monopoly by limiting what fucntionality third party apps can use while delivering its own solutions. Wallets is a prime example, and its been going on since Apple first introduced NFC capabilities into its SmartPhones.

The broader issue here is Banks themeselves are getting overcharged to deliver Apple and to an extent Google Pay - if the phones allowed competition, then banks would support those apps that delivered the best experiences at the right price points for them. With choice, I would be using a third party wallet and not Apple or Google pay thats for sure

I have spoken about making the receiving firm pay the compensation for a long time now. Moving to 50:50 is a good step change, but I still maintain that the receiving firm needs to be held more accountable - after all it has received the funds and it is holding those funds in many cases. It also ensures the level of monitoring on receipts is improved, which not only helps fraud, but also various other aspects of financial crime. 

The real step change though is when we finally stop making push payments based on account numbers, rather we make them based on a verifiable identity  - CoP helps, but its a sticky plaster over the bigger issue.

There is a solution coming to market in 2024 (early) that solves these scams and dissiniformation.....Will post the link closer to the time

I think Programmable banking is the future of banking, blend that capability with the rapid developments in AI and you can soon see the end of banks having to provide PSD2/Open Banking type API specifications, simply because integrators can simply program that capability directly into the bank core....There are so many benefits to this over the rather dated approach of APIs and tokens used for granting third party access.

Pave also shows that, any form of digital money is programmable, including FIAT. It's not just about programming the asset, its about programming how it is held, and what you want to do with it, including access - thats a programmable personal bank.

Massive congratulations to the team, its a fantastic advancement in finance....

One question / food for thought. Should CHAPS be the only High Value Payment infrastructure the UK has? Since CHAPS is tied to the RTGS so tightly in the UK, should we not have an independent High Value Payment solution that is not CHAPS and not run by the BoE? 

This would remove the link between CHAPS outages and RTGS outages and therefore ensure significnat resilience in the UKs payment infrastructure. 

To follow on from the comments of DLT. I think we would find that any DLT solution would see nodes running under the control of the central bank and limited (non cloud) infrastructure. The resiliency benefit of DLT at that point would be pretty much the same as what we see today. In addition, operating a DLT is a signifincant technical uplift which introduces a number of challenges for the BoE and the SMF members. Why have such a heavy left for such a limited benefit.

There are much better ways of working that see an almost negligent level of investment required.

The outage shows that there is a strong need for the RTGS system to be upgraded sooner rather than later. It also shows the critical importance of two other, often overlooked aspects of such a systemic system:

1. CHAPS and the RTGS are too tightly coupled, a high value payment system shouldnt necessarily need to have the RTGS up all the time, therefore reducing any "blast radius" of an issue in the RTGS significantly

2. An RTGS really should have a resilient secondary system (not built on the same code base as per the primary, rather it should be a non-similar facilitaty (NSF)) that is used on a daily basis by all the members. If we had this system in place - then an outage would mean members of the SMF would simply see processing via the NSF. 

The demands are long overdue, with the exception of point 3. Rates are rates, if you offer a poor rate customers wont use you - but that's only possible if rates and fees are fully transparent. That is the issue here.

The other challenge is, for many banks and the way the current outdated model of correspondent banking works, means sometimes the bank (or FinTech) cannot give an accurate price upfront, simply because of the way in which correspondents charge. Still today the result is often the beneficiary not receiving what the sender orignally sent / thought they would receive. This is one of the aspects that I've been working on to address with RTGS.global, ensuring a) correspondent banking model changes to be based around central bank funds, removing friction, risk and cost and b) that the end customer benefits from a transpareent rate and non-deducted fee structure.