Cloud Architecture and Governance for a Regulated Bank
Leap Associates capability: designing an offshore cloud workload a bank’s technology steering committee and its regulator will both approve
1. Context
A commercial bank wants to launch a digital lending product. The technology partner that can deliver it fastest hosts its decision engine and loan management system offshore, on international cloud. The bank’s risk, compliance and technology functions have to decide whether that is permissible, and the regulator has to be satisfied separately.
This is now one of the most common blocking problems in emerging-market banking. The commercial case is obvious and the regulatory path is not. Most attempts fail in one of two ways. Either the bank refuses the architecture outright and loses the product, or it approves something loosely defined and discovers at the regulatory gate that the arrangement is classified as material outsourcing, which triggers obligations nobody planned for.
The determining question is not whether cloud is allowed. It is where the regulated control points sit.
2. The design principle
An offshore cloud workload becomes acceptable when the bank can demonstrate, component by component, that it has retained everything that makes it a bank.
That means drawing an explicit boundary. On the bank’s side of the line: the customer channel, the system of record, disbursement, accounting and the general ledger, the audit trail, reconciliation, customer communication, and regulatory accountability. On the partner’s side: decision support, scoring, analytics, explainability and monitoring.
Under that split the partner never becomes the system of record, never controls disbursement, and never holds the customer relationship. The workload can then be argued as non-material, because the bank has not outsourced any function that would impair its ability to operate or to be supervised if the partner disappeared tomorrow.
The classification is not a label applied at the end. It is a set of conditions that has to remain true throughout, and the architecture has to be designed so that it stays true.
3. What the work involves
Component ownership matrix. Documenting every layer of the architecture and assigning it to the bank or the partner, with no ambiguous entries. This is the artefact that a technology steering committee actually argues over, and the one most programmes do not have.
Data boundary design. Establishing exactly what crosses the border. Personally identifiable information stays inside the bank. What leaves is masked and enriched data sufficient for a decision and nothing more, with the masking and tokenisation layer owned by the bank rather than the partner.
Materiality assessment. Building the case for the workload’s classification against the regulator’s outsourcing framework, and setting out the conditions under which that classification would change.
Security and key control. Bring-your-own-key and hardware security module arrangements so the bank retains cryptographic control of its own data, identity and access management, security operations centre integration, logging, and independent vulnerability assessment and penetration testing.
Resilience and exit. Disaster recovery design, business continuity, and a genuine exit plan. Exit is the clause examiners test hardest, because an outsourcing arrangement the bank cannot unwind is a material one regardless of what the classification says.
Contractual specification. Translating the architecture into a service level agreement covering data, regulatory compliance, service levels, settlement, exit and dispute resolution, and ensuring it overrides the commercial agreement wherever the two conflict on regulatory matters.
Two separate approval packages. An executive support note structured for the bank’s internal technology steering committee, and a distinct regulatory information-readiness pack aligned to the central bank’s cloud outsourcing framework. These are different audiences asking different questions, and conflating them is a common cause of delay.
Model and AI governance. Where the decision engine uses machine learning, the explainability, model documentation and decision-logging needed for the bank to defend an individual credit decision to a customer or a regulator.
4. What this means for a client
Materiality is designed, not discovered. Banks routinely negotiate the commercial deal first and assess outsourcing materiality afterwards. By then the architecture has already determined the answer. Run the materiality assessment while the architecture is still changeable.
The steering committee and the regulator are different audiences. An internal committee is asking whether the bank is taking prudent risk. The regulator is asking whether the bank remains supervisable and its customers protected. One document addressed to both usually satisfies neither.
Retaining the ledger is what preserves the licence. As long as the bank holds the system of record, the disbursement rail and the audit trail, almost any analytical or decisioning workload can be placed with a partner. Give up the ledger and no amount of contractual drafting recovers the position.
Exit is the real test. Boards and examiners both look hardest at what happens when the arrangement ends badly. An exit plan that cannot be executed within a defined period, on the bank’s own infrastructure, undermines the entire case.
Cost sharing is a governance question. How infrastructure cost is split between bank and partner shapes who controls scaling, tooling and security spend. That is an operational control matter, not just a commercial one.
5. Relevant capability
Cloud outsourcing strategy and materiality assessment, regulatory submissions under central bank cloud frameworks, bank and fintech partnership architecture, data residency and masking design, key management and security control design, resilience and exit planning, outsourcing service level agreements, and AI and model governance for credit decisioning.
This describes a capability and a recurring problem pattern drawn from Leap Associates’ advisory work. It deliberately names no client, no technology vendor and no commercial terms, and describes no specific live engagement.