Four things worth verifying before you sign — and the answers that separate a team that has done this from one that has read about it.
This article is provided for general information and does not constitute legal or regulatory advice. It reflects publicly available sources as at the date of publication. Regulatory expectations and timelines change; confirm your own position with your compliance function and the relevant authority.
Banking software is rarely built in isolation. A new service has to connect to core systems, identity, payment rails, data platforms, risk controls and operational processes that already carry business-critical workloads — most of them on release calendars and change-approval cycles set long before the project existed.
That is why the application itself is so rarely the hard part, and why choosing an engineering partner for banking work is not the same exercise as choosing one for a product build. A team can build the feature in six weeks and spend six months discovering what it touches. The second number is the one that decides whether the release lands — and it is almost never the number in the proposal.
Most proposals look alike at the point of signing. They differ at the point of integration, which arrives months later, when changing partner is expensive. So the useful work happens before the signature: four things worth verifying, each with an answer that distinguishes a team that has done this from one that has read about it.
What follows is the questionnaire we would hand a technology owner running a selection process — including one being run against us. For the commercial side — scope, engagement model and service coverage — see our financial software development page.
A credible integration plan starts from discovery, not from a target architecture. Anyone who proposes the target state in the first meeting is showing you a template with your logo on it — the constraints that will actually shape the design have not been looked at yet.
Discovery is worth judging by what it produces, not by how long it takes. A reasonable set of outputs:
A system context model showing the boundary of the change;
A dependency map that separates synchronous calls from batch;
Non-functional requirements with numbers in them, not adjectives;
A data-flow diagram with an owner attached to each source;
A risk register that survives into delivery rather than closing with discovery; and
A transition plan covering cutover, rollback and support.
The batch line deserves particular attention in core banking work. A core platform with an overnight window behaves nothing like an API you can call whenever you like, and a design that assumes real-time availability against a batch-bound system fails in a way that only shows up at month end. Teams that have worked inside core banking platforms and open banking API layers ask about the batch window early, because they have been caught by it before.
Compliance cannot sit in a separate document reviewed near the end. The delivery model should show the path a requirement takes: from a policy statement, to an architectural decision, to a backlog item with acceptance criteria, to a test, to a piece of release evidence — traceable in both directions when someone later asks why a control exists.
In practice this means the institution's Technology, Risk, Security and Compliance owners sit in the design and release decisions that concern them, rather than reviewing outcomes afterward. We describe this as a governance pattern worth recommending, not a claim that every engagement runs an identical approval process — the right structure is the one that fits the bank's own change framework. The same evidence problem, applied to AI-assisted workflows, is the subject of where RegTech and AI actually overlap.
Hong Kong's operational-resilience expectations, set out in HKMA supervisory material, center on the ability to keep delivering critical operations through disruption. For an integration project that translates into five specifics, and all five are questions about rehearsal rather than documentation:
What the fallback is when the new component is unavailable;
How rollback is exercised, not merely written down;