The core cannot do what the channels promise
Customer-facing services assume real-time behaviour the core settles in batch. The compensating layer becomes critical infrastructure that nobody designed and few fully understand.
Technology consulting for banking and financial services
Financial services estates are defined by two things: transactions must be correct rather than approximately correct, and a regulator may ask how any figure was produced. Almost every architectural constraint in the sector follows from one of those.
Industry overview
Banking estates are among the longest-lived in enterprise technology. Core systems frequently predate the channels built on top of them, and the gap between what the core can do and what customers now expect is bridged by layers of integration accumulated over years.
That gap is where most of the difficulty sits. Real-time payment rails, instant onboarding and continuous availability place demands on a core that was designed for batch settlement and overnight windows, and the middleware compensating for that difference becomes load-bearing without ever having been designed as such.
Our work here is usually about making the core's limitations explicit, designing the layer around it deliberately rather than by accretion, and producing the lineage and evidence a regulator expects as a by-product of operation rather than as an annual project.
Business challenges
What financial services organisations bring to us most often.
Regulatory evidence is an annual project
Producing lineage, access history and control evidence requires manual assembly each cycle, because the controls were documented rather than expressed as configuration.
Reconciliation absorbs real capacity
Systems disagree, so teams reconcile. Where the disagreement is structural rather than incidental, that effort recurs indefinitely and grows with volume.
Change windows are narrow and shrinking
Availability expectations have risen while the release process still assumes scheduled outages, so changes are batched and each release carries more risk than the last.
Fraud and security controls conflict with experience
Controls added independently accumulate friction, and the customer journey degrades in ways no single control owner is accountable for.
Vendor concentration in the core
A small number of platforms carry the critical function, and the switching cost is high enough that the relationship shapes the roadmap.
Digital transformation challenges
Core replacement is the most consequential decision a bank's technology function makes and the one most likely to be attempted as a single programme. Where it is, there is no increment that can be delivered independently and therefore no point at which the programme can be corrected without losing what has been spent.
The alternative that works more often is to reduce the core's responsibility progressively — moving product, pricing, onboarding and channel logic out of it into services that can change at their own pace — so that whether the core is eventually replaced becomes a smaller question.
- Capability moved out of the core in increments, each with its own business case
- Reconciliation designed in during transition, because two systems will run in parallel
- A rollback position defined per increment and verified before it is needed
- The old path retired deliberately rather than left running indefinitely
Regulatory considerations
Financial services carry the broadest evidential burden of any sector we work in. Reporting obligations, data residency requirements, audit trail expectations and customer data protection under the Digital Personal Data Protection Act each place constraints on architecture rather than on documentation.
The design principle that reduces the cost most is generating evidence as a by-product of operation. Where controls are expressed as configuration and lineage is derived from the pipeline that moves the data, an audit becomes a query rather than a project.
We advise on technical design and evidence architecture. We do not provide legal or regulatory opinions, and we do not represent NG&NR as holding certifications it has not been awarded.
- Lineage derived from the transformation code rather than maintained separately
- Controls expressed as configuration so evidence is continuous, not assembled
- Residency and processing location settled before provider or platform selection
- Access and change history retained in a form an examiner can interrogate
Enterprise architecture approach
The defining architectural question is where the boundary sits between the system of record and everything built around it. Where that boundary is implicit, business logic leaks in both directions and the estate becomes impossible to change safely.
The second question is consistency. Financial transactions have correctness requirements that do not tolerate the eventual-consistency patterns used freely elsewhere, and the architecture has to state clearly which operations require strict guarantees and which do not.
- An explicit boundary between the system of record and the services around it
- Consistency requirements stated per operation rather than assumed globally
- Idempotency designed into every financial operation, not added after a duplicate
- Degraded-mode behaviour defined for each channel when the core is unavailable
Cloud strategy
Cloud adoption in banking is a regulatory and concentration-risk conversation as much as a technical one. Residency, the regulator's expectations around outsourcing, and the exit position if a provider relationship ends are all design inputs, not procurement details.
In practice, channels, analytics, testing environments and recovery capacity move first and deliver most of the benefit, while the core moves on a longer horizon or not at all. We are explicit that a hybrid position held deliberately is a legitimate target state, not a failure to finish.
- Residency, outsourcing and exit positions established before provider selection
- Concentration risk assessed honestly, including where a single provider is acceptable
- Channels, analytics and recovery moved ahead of the system of record
- Recovery objectives derived from financial and regulatory consequence
Data strategy
The data requirement in banking is unusual in that correctness must be demonstrable, not merely achieved. A figure that is right but cannot be traced to its source is a finding, and the effort to trace it after the fact recurs at every reporting cycle.
The second requirement is definitional. Where the same metric is calculated differently in risk, finance and operations, reconciliation consumes capacity indefinitely — and that is a semantics problem no reporting platform resolves.
- Metrics defined once with an authoritative source and a named owner
- Lineage that answers an examiner's question without a manual investigation
- Quality tested in the pipeline, with agreed behaviour when a test fails
- Personal data minimised outside the systems that genuinely require it
Security considerations
Financial services attract targeted rather than opportunistic attack, which changes the design emphasis. Identity is the primary control plane, and privileged access to systems that move money warrants time limits, recording and separation of duties rather than standing entitlement.
Fraud controls sit alongside security controls and are frequently owned separately, which is how customer journeys accumulate friction that no individual owner is accountable for. Designing them together produces better outcomes on both axes.
- Privileged access to money movement time-bound, recorded and separated by duty
- Fraud and security controls designed together rather than layered independently
- Transaction integrity protected by design, including replay and duplicate handling
- Third-party and partner access inventoried, with a bounded blast radius
Software engineering
Engineering in this sector is constrained by evidence and by change windows. Both improve with the same intervention: controls enforced in the delivery pipeline, which apply to every change automatically and produce their own audit trail.
That is also what makes smaller, more frequent releases possible, and smaller releases are less risky than the batched ones a narrow window otherwise forces. The slow version of governance is the one applied as a gate at the end.
- Approval and separation-of-duty evidence produced by the pipeline, not by email
- Calculation correctness tested as a first-class requirement, with expected values
- Idempotent, replay-safe operations wherever money or position is affected
- Release size reduced deliberately, because batching is the larger risk
Integration strategy
Payment and settlement integrations have properties most enterprise integrations do not: messages must not be lost, must not be applied twice, and frequently must be applied in order. Those requirements have to be designed rather than assumed from a transport.
Partner and scheme integrations add a second constraint — the contract is set externally and changes on someone else's timetable — which makes version tolerance and clear failure behaviour a structural requirement rather than a refinement.
- Exactly-once effect achieved through idempotency rather than assumed from transport
- Ordering requirements stated per flow, because not every flow needs them
- Reconciliation designed as part of the interface, not bolted on afterwards
- Externally-set contracts handled with version tolerance and explicit failure paths
Recommended NG&NR services
The services usually engaged first in this sector, and why.
Enterprise Architecture
Setting the boundary between the system of record and everything around it, and stating consistency requirements per operation.
Cybersecurity
Privileged access to money movement, transaction integrity and the third-party access that determines blast radius.
AI & Data Engineering
Metric definitions held once and lineage derived from the pipeline, so an examiner's question is a query rather than an investigation.
Cloud Consulting
Residency, outsourcing expectations, concentration risk and a credible exit position — established before provider selection.
Software Development
Idempotent, replay-safe services around the core, with approval evidence produced by the delivery pipeline.
QA & Test Automation
Calculation correctness tested against expected values, so smaller and more frequent releases become defensible.
Recommended technologies
Selected against the constraints above, not against a preference. We hold no vendor partnerships.
Java
The runtime a large share of core banking and payment middleware is built on, and where most modernisation of it happens.
.NET
Common across channel, servicing and internal platforms, with a supported path off .NET Framework.
Databases
Where correctness is enforced. Transaction semantics and retention design here are the ones a regulator asks about.
Kubernetes
For the services layer around the core, where independent release cadence is the point rather than a side effect.
Microsoft Azure
Frequently the incumbent platform, and where identity and regional residency requirements are most readily satisfied.
AWS
Where breadth of managed services and multi-account isolation suit the separation regulated workloads require.
Delivery approach
How an engagement runs where correctness must be demonstrable.
Free first consultation
Your estate, the constraint you are experiencing, and whether it is a core, integration, data or delivery problem.
Assessment against the running estate
Core boundary, integration topology, reconciliation load and evidence production, established from the systems rather than the documentation.
Obligation and evidence mapping
Reporting, residency, retention and audit expectations recorded as hard architectural inputs before design begins.
Target architecture and sequencing
Core boundary, consistency requirements and an increment plan where each step carries its own business case.
Delivery with your teams
Your engineers implement while we review design, test assumptions and validate that evidence is genuinely produced by the pipeline.
Handover
Decision records, runbooks and ownership, so the design survives the people who wrote it.
Frequently asked questions
Frequently the better question is whether you can reduce its responsibility instead. Moving product, pricing, onboarding and channel logic into services that change at their own pace delivers most of the benefit in increments, each with its own business case — and makes eventual replacement a smaller decision rather than a single programme with no safe stopping point.
By designing the compensating layer deliberately rather than letting it accumulate. That means stating which operations require strict consistency, making every financial operation idempotent, and defining what each channel does when the core is unavailable — rather than discovering that behaviour during an incident.
Largely, yes, and that is where the cost reduction sits. Where controls are expressed as configuration and lineage is derived from the transformation code, an audit becomes a query. Where they are described in documents, every cycle is a project.
For many workloads, subject to residency, outsourcing expectations and a credible exit position — all of which are design inputs rather than procurement details. Channels, analytics, testing and recovery typically move first. A deliberate hybrid position is a legitimate target state, not an unfinished migration.
Almost never. It is usually a definition problem: the same metric calculated differently in each function because semantics were never agreed and no source is authoritative. A new reporting platform reproduces the disagreement faster.
By designing for the properties that matter — no loss, no double application, and ordering where the flow genuinely requires it. Exactly-once effect comes from idempotency in the receiver rather than from a guarantee assumed of the transport, and reconciliation is designed as part of the interface.
Usually yes, and it reduces risk rather than adding it. Where approval and separation-of-duty evidence is produced by the pipeline automatically, smaller releases become possible — and a batched release carries more risk than several small ones because more changes are in flight at once.
Designed alongside security controls rather than separately. Where they are owned independently, each control is reasonable and the accumulated friction in the customer journey is nobody's accountability. We look at the journey and the control set together.
It is a real consideration and we assess it honestly, including the cases where a single provider is the right answer. Multi-provider architecture carries genuine cost in identity, networking, observability and skills, and adopting it for a risk you have not quantified is a poor trade.
No. We do not publish case studies or name clients in any sector. During the first consultation we work through the reasoning on your own estate, which is a better test of our judgement than a reference list.
By separating structural disagreement from incidental. Incidental differences are timing and are fixed operationally. Structural differences mean two systems hold the same entity with different rules, and no amount of reconciliation effort resolves that — it requires deciding which system masters the entity and making the other derive from it.
The obligations scale down less than the estate does, which is precisely why architecture matters more at smaller scale rather than less — there is less capacity to absorb the cost of getting it wrong. We scope to what is warranted and will say plainly when an engagement is not yet worth its overhead.
Next step
Discuss a financial services estate
A free first consultation covering your core boundary, the integration layer around it, and whether the constraint you are experiencing is architectural, definitional or a matter of delivery process.
No cost, no obligation. Pricing is transparent and includes GST.