Blog· min March 13, 2023
In the past two decades, technology has revolutionised the finance industry. Whilst I’m sad that many will no longer experience the joy of a rectangular signed piece of paper (also known as a cheque) appearing in a birthday card, my concerns pretty much end there. Payment experiences are slicker, banking interfaces have dramatically improved, and people can interact with their money in a more meaningful and transparent way.
It's not just the sexy user interfaces or ‘external assets’ that are moving in the right direction – traditional banks are also making progress in updating their core platforms. The shift towards modular systems where cost ratios can be reduced, and efficiencies gained is definitely gathering pace and is being seen as a necessity to compete This is enabling these laggards to catch up with their newer counterparts and interact with their customers in a myriad of different ways.
However, one area that has not received much attention is the way banks connect to their endpoints or partner banks. The same technology and technical setup have been used for the last 40 years, and it is not a common set of standards across the industry. While you can control what happens within your own bank, the reality is that banking relies heavily on other banking partners who may not have the same level of quality or design. This is particularly true when it comes to tackling one of the most fundamental areas of financial technology: account-to-account payments.
There have been so many amazing companies that have changed the way we pay and get paid. Push payments direct or via open banking (Trustly, Truelayer) BNPL (Klarna, PayPal, Apple), recurring payments (Gocardless), what I call Super Acquirer/PSPs (Adyen, Checkout), challenger banks (Qonto, Monese) the list goes on. However, in addition to this, there are plenty of tier 2 and 3 banks that process at scale who aren’t Direct participants but still need to stay relevant and keep costs low in today’s market.
When these companies want to move the money they have collected, they must do so by having access to the scheme that will best facilitate the use case. For instant bank transfers in the SEPA region, this is RT1 and/or TIPS. For non-immediate payments and direct debits, this is STEP2 for SCT and SDD. Traditionally these companies have had 2 options which is driven by the license they hold:
However, there is a third way that Form3 has pioneered in the UK and launched across Europe, called Direct Non-Settling Participant (DNSP). This unique model blends the two traditional models by leveraging the liquidity of a Direct Participant but sending payment messages directly to the scheme.
Customers using this access model are provided with the benefits of direct technical access to the SEPA Instant clearing system. In collaboration with one of our partner banks messages are exchanged in such a way that this is experienced as if they were direct participants, same messages and same speed. Settlement happens on a settlement account held with the partner bank where our customers manage their own liquidity with the partner bank. This Access Model brings the DNSP Participant as close as possible to the clearing system without the need to hold a settlement account at TIPS.
How the direct non settling participant solution model works.
Traditionally the route of becoming a SEPA indirect participant has been the one taken by PSPs and more regionally focussed banks. While it is a lighter process than becoming a direct participant, it still represents a sizeable project. However, there are still many ways that an indirect model may be failing you. Let’s look at the problems associated with an Indirect model approach and see how DNSP can solve for them:
Meshing New technology on to old
You are an API first company or have recently re-platformed to a modern core and you read the specs of your Direct Participants connectivity, and it’s likely to be host to host. They might expose an API but it’s fragmented and cumbersome to work with. Most of the communication is file-based requiring a unique set of messaging standards. It is certainly not re-usable nor is there the facility to test effectively in sandboxes. Integration support is limited.
DNSP: With cloud-native API send JSON messages direct to scheme. Simulators let you test all happy and un-happy paths. All projects are standardised and run to pre-defined implementation timelines.
Different Integrations across schemes
The integration will be very different across the SEPA schemas. That is 3 completely different integrations, pulling reports in 3 different formats.
DNSP: The same set of API resources are re-used across the different schemes making the addition of new schemes simple and quick.
Incomplete bank integrations
Some banks have chosen not to offer all SEPA schemes to their FIs, and certain exception and enquiry message types are not covered. This means FIs often have to use 2 or 3 banks to cover all their SEPA requirements.
DNSP: All SEPA schemes are covered and the full set of message types that a direct participant must test for and deploy are available for DNSP addressable PSPs.
When and FI sends their payments to their Direct Participant, every single transaction is monitored and screened. Rule based systems often create false positives, especially when the direct participant is not familiar with the business models the FI is in. Often rules are generic and based from corporate client bases.
DNSP: All screening is done by the FI with the technology selection, methodology and processes all owned and managed by them. This is huge as the FI knows their customer better than anyone else and can tailor rules accordingly.
Having another party in the flow of messaging always introduces risk and latency. As FIs scale up and their volume increases, the legacy estates of direct participants can begin to throttle transactions and dictates throughput to the scheme.
DNSP: The FI is in full control of transaction throughput as messages are sent directly to the scheme.
SEPA Scheme changes
In SEPA world, we are all accustomed to the yearly changes that are announced and mandated for change late in the year. This can heavily impact software integrations.
DNSP: Form3 has never had downtime when deploying new releases, where we have multiple releases per day. Scheme changes are no different and Form3 absorb the changes and format these into the API that FIs consume.
High cost: as volume scales, the full scope of costs do not trend downwards with volume. It may be that transactions costs can fall, but R (recalls, returns, refunds) messaging costs are where the banks make the lion share of their revenue.
DNSP: For high volume FIs can reduce total cost of ownership significantly.
A thorough assessment of the FIs business model must be undertaken to make sure that the right connectivity and setup is chosen. At Form3, we love the details of exploring what works and how we can design models that are fit for an API first, Instant, 24x7 world. We can also ensure that our API integration for DNSP is also the same for being a Direct Participant. So, when FIs migrate from PI/EMI to credit institution, you are covered. This is also important as the EPC’s discovery exercise of granting non-banks direct access to SEPA is still being considered and will be a game changer in opening more competition within SEPA to create a more democratic payment landscape.