top of page

Frontier Tech Has a Plumbing Problem

1 hour ago
3 min read
Frontier Tech Has a Plumbing Problem

By Georgijus Kocegarovas, Co-Founder and Chief Legal Officer at Baseella


Every conversation about frontier technology in financial services arrives at the same shortlist: artificial intelligence, quantum computing, tokenised assets. All three deserve attention. But in regulated payments, whether any of it lands depends on something less photogenic – the core underneath, and how many other systems it has been connected to.


The orchestration orthodoxy


For over a decade, the accepted wisdom has been to assemble best-of-breed components: one provider for accounts, another for onboarding, a third for transaction monitoring, a fourth for screening, a fifth for CRM, a sixth for a customer-facing interface, all coordinated by an orchestration layer sitting on top of the core banking system. On a slide, it looks like optionality and the best setup possible. In practice, it forces the operations team to work across more than five windows to get through a single day, and the orchestration layer becomes a critical dependency that owns none of the underlying data.


It also assumes the pieces beneath are as modern as the interface in front of them; frequently they are not. A polished front end over a twenty-year-old ledger is a designer tap connected to ageing pipes: it may look modern at the surface, but when the plumbing fails, everything upstream of the user experience fails with it.


Real time changed the arithmetic


The deeper problem is that many of those legacy cores were built for batch. Files in, cycle runs, positions update overnight, everyone reconciles in the morning- that was entirely sensible when payments settled in days, but that’s not the case anymore. Domestic instant rails clear in seconds, card authorisations are immediate, and cryptocurrency transfers do not observe weekends, bank holidays or the end of the business day. Clients now ask for stablecoin payments as a matter of routine, and while the firm rarely settles on-chain itself (quite often it connects to an exchange or custodial provider), the core still has to act as the ledger of record, in real time, for something that never stops moving and is irreversible.


Layer that onto a fragmented estate and the arithmetic gets uncomfortable. Each integration is a boundary at which state is duplicated: a balance exists in two places, a transaction status in three. If those copies only converge on a batch cycle while money moves in seconds, there is a window in which nobody can say with confidence what the position actually is. Most of the time the copies agree, which is precisely why the problem stays invisible until it doesn't. That is not theoretical- safeguarding reconciliation, transaction monitoring, travel rule compliance, and regulatory returns all assume a single authoritative record. If that data has to be stitched together from three systems, you will discover the gap at the worst possible moment. And reconciliation is only half the problem: real-time payments now operate within legally defined end-to-end processing windows. When a payment has to travel through separate APIs for processing, screening and monitoring before it can reach the clearing rail, every integration consumes part of that latency budget and introduces another point of failure.


Every integration is someone else’s promise


Security compounds it further, as every integration means credentials, keys, endpoints and another vendor's supply chain attached to your perimeter. Supervisors have caught up: DORA required EU financial entities to maintain a Register of Information on ICT third-party arrangements, and the FCA's PS26/2 (in force from March 2027) introduces a UK third-party register and incident reporting framework with a comparable purpose: structured visibility through supply chains to identify concentration risk. Most firms discover the true size of their dependency map while filling that register in, and it is rarely a comfortable afternoon.


The same architecture decides how the next question is met. Almost nobody in payments is asking about post-quantum cryptography yet, which is less complacency than a badly framed question: when quantum breaks encryption is unanswerable and therefore easy to defer, whereas how many systems in your estate hold keys, and whether an algorithm could be changed without renegotiating nine supplier contracts, can be answered today. Much of the AI now pitched into payments is the same problem in reverse: an intelligent layer offered to reconcile systems that should not have needed reconciling. That is an expensive way to avoid fixing the foundation.


None of this is an argument about features; it is an argument about boundaries. Each one removed is a reconciliation that no longer runs, a latency budget no longer spent, a set of keys that no longer sits somewhere else, one audit trail rather than several. It is why the feedback we hear at Baseella is rarely about a single capability, but about running daily operations from one interface of a single system. So the duller question comes first: can the core absorb it without another integration? The plumbing decides who reaches the frontier.

 
 
bottom of page