I work on a merchant lending platform that moves millions of transactions a day. Most of what my team does is unglamorous — service boundaries, data contracts, API governance, keeping a distributed system comprehensible while it grows. But the ground underneath that work has genuinely shifted, and it is worth separating the real changes from the ones that only sound big.
Real-time settlement broke batch thinking
The single most consequential change is that money now moves instantly, irrevocably, and at three in the morning on a Sunday.
Legacy payment systems were built around a daily cycle. Transactions accumulated, a batch ran, positions were reconciled, and the next day started clean. An extraordinary amount of banking software has that rhythm baked into assumptions nobody wrote down: that there is a quiet window for maintenance, that a reconciliation break has hours of slack, that a duplicate can be caught before it settles.
Instant payment rails remove all of it. The properties that matter for anyone building on them:
- Irrevocable. There is no chargeback. A mistaken payment is recovered by asking nicely.
- Always on. There is no maintenance window. Your deployment strategy must be zero-downtime, not "Sunday 2am".
- Seconds, end to end. Which means fraud scoring, sanctions screening and limit checks all happen inline, in the critical path, with a latency budget.
- Push, not pull. Credit-push semantics change the fraud model completely — the loss shifts from card-not-present fraud toward authorised push payment fraud, where the customer was tricked into sending money themselves.
That last point is the one banks are still absorbing. When the customer authorises the payment, no traditional control fires. The defences that work are behavioural — is this account behaving unusually, is this beneficiary newly created, does this transaction match a known scam pattern — which is a graph and sequence-modelling problem rather than a rules problem.
ISO 20022 is a data migration that people keep calling a format change
Describing ISO 20022 as "a new message format" undersells it in a way that causes projects to be scoped wrongly.
The old formats were terse, positional and lossy. Remittance information got truncated into free text. Party identification was inconsistent. Reconciliation on the receiving end meant heuristics.
The new format is structured, extensible and considerably richer: proper party data, structured remittance information, purpose codes, and enough room to carry what the payment was actually for.
The migration difficulty is not parsing. It is that:
- Your internal canonical model is probably the old format's shape. Every downstream system that assumed a 35-character reference field now truncates data it should carry.
- Richness must survive end to end. Accepting a structured message and flattening it into a legacy core is compliant and pointless — the value was in the structure.
- Coexistence lasts years. You will translate in both directions, and lossy translation is where the reconciliation breaks come from.
The teams that got value out of this treated it as a canonical-data-model project with a message format attached. The teams that treated it as an adapter at the edge shipped on time and got nothing.
Cards became tokens and nobody outside noticed
The visible surface of card payments has not changed much. Underneath, the credential itself did.
Network tokenisation replaces the card number with a token that is restricted in scope — often to a specific merchant or channel — and can be updated when the underlying card is reissued. That last property is worth more than the security benefit for anyone running subscriptions: the token survives a card expiry, so recurring revenue stops silently failing.
For architects the important consequences are boring and structural:
- Your systems should never see or store a raw card number. Not encrypted — absent. Scope reduction is the entire strategy.
- Tokens are not interchangeable across contexts, so "the card" is no longer a single identifier you can join on. Customer identity has to be resolved some other way, deliberately.
- The current PCI DSS revision pushed hard on continuous validation rather than annual point-in-time evidence, which means the controls need to emit evidence automatically or your engineers will spend a quarter a year producing screenshots.
Open banking's second act is data rights, not APIs
The first wave of open banking was regulatory API mandates producing technically functional, commercially thin ecosystems. Lots of account aggregation, not much else.
What changed the calculus is the shift from "banks must expose APIs" to consumers own their financial data and can direct where it goes, with screen scraping being actively deprecated in favour of authorised, revocable, token-based access.
For an incumbent this is genuinely strategic rather than a compliance line item, because it makes switching cheap. If a customer's transaction history is portable, the deposit relationship stops being sticky by default. The engineering response — consent management, granular scopes, revocation, audit — is not hard. Deciding what your product is when the data moat drains is harder.
Core modernisation, honestly
Every bank has a core banking system it cannot replace and cannot leave alone. I have watched enough of these to have a view.
Big-bang replacement fails at a rate that should have ended the practice. What works is the strangler pattern, and the reason it works is that it lets you be wrong incrementally:
// The whole trick: one interface, two implementations, routing that is a
// runtime decision rather than a deployment. The flag is not a nicety —
// it is the rollback path, and it is why this migration can be attempted
// during business hours.
public AccountBalance balance(AccountId id) {
return featureFlags.enabled("balance.modern", id)
? modernLedger.balance(id)
: legacyCore.balance(id);
}
Two lessons I would pass on. First, read paths migrate before write paths, because a wrong read is an incident and a wrong write is a restatement. Second, run both implementations in parallel against production traffic and compare outputs before you cut over — shadow reads find the undocumented behaviour that the legacy system has been relying on for twenty years, and there is always some.
The trap is stopping halfway. A strangler migration that stalls leaves two systems, two data models and a routing layer, which is worse than either endpoint. Somebody senior has to own finishing it.
What I am watching
Stablecoin settlement for cross-border, where the correspondent banking chain is slow and expensive enough that the alternative is worth the regulatory friction. Still more pilot than production, but the direction is clear.
Agentic commerce. If an agent initiates a purchase on a customer's behalf, the authorisation model has to express delegated, bounded authority — this agent, this merchant, this limit, this window, revocable. That is a different primitive from a card credential, and the schemes are actively defining it.
Quantum-safe migration. Long-lived financial data encrypted today is exposed to future decryption, and inventorying where cryptography lives in a bank is a multi-year exercise that has to start before the deadline is visible.
The thread running through all of it: the assumptions that got baked in when settlement was slow, credentials were static and data was captive are the ones now expiring. Most legacy in banking is not old code. It is old assumptions with new code written on top.