Search for a command to run...
A guide to building cloud infrastructure that meets prudential obligations and still ships fast.
No comments yet. Be the first to comment.
Cloud speed and regulatory confidence aren't a trade-off—they're a design choice. So is building AI platforms responsibly. This series is for technology leaders at financial institutions navigating modern cloud infrastructure, AI governance, and regulatory compliance in parallel. From landing zone architecture to model governance to board communication, you'll discover the operating patterns that let you move faster while staying within regulatory tolerance. Not as compromise. As strategy.
The shift from doing to leading is more complete than anyone warns you. Here is the map.
A diagnostic framework to see where your cloud function sits and what closes each gap. TLDR Banking cloud maturity is not a single dimension. A bank can be sophisticated in infrastructure automation
Why prudential standards are the most powerful design constraints in your toolkit. If you know how to read them.
The shift from doing to leading is more complete than anyone warns you. Here is the map.
Enterprise Cloud & AI Platform Engineering | Executive Perspectives
4 posts
This blog explores how to build and operate cloud and AI platforms in a regulated Financial Services environment, where innovation must be balanced with security, resilience, cost discipline, and regulatory obligations. It takes a practical view of platform engineering, AI delivery lifecycle (AI‑DLC), FinOps, and operational resilience, treating compliance as a design input rather than an afterthought.
Cloud in banking is not a technology choice with extra compliance overhead. It is a fundamentally different operating model. Banks are accountable for trust; that accountability forces different architecture decisions, governance disciplines, and incident response timelines than tech companies. This article walks through what changes—and why it changes—using APRA's Prudential Standard CPS 230 as the reference framework.
It's 2:17am. A major cloud dependency is degrading. Not cleanly failing, just getting weird in the way only distributed systems can. Authentication is intermittently slow. Customer channels are stuttering. Payments are backing up. The on-call chat is filling with screenshots, graphs, frustration, and half-formed theories.
Then the call drops into silence as someone senior asks the only question that matters in a bank:
"Are we still operating within tolerance?"
Not "did we follow CSP best practice?" Not "did we deploy across three availability zones?" Not "can we scale out?"
Tolerance. Because in banking, cloud is not a technology decision. It is a component of an institution's trust system, and the regulator now hard-codes that reality into how banks must operate.
This is where the advice "just follow hyperscaler best practices" becomes technically correct and operationally dangerous.
In a startup, cloud is a growth lever. You optimise for speed, optionality, experimentation. You can absorb some failure because the downside is mostly internal: missed targets, unhappy users, a big post-mortem, an apology.
In a bank, cloud is a survivability system. The downside is measured in customer harm, financial instability, and institutional confidence. That difference is not cultural. It is structural.
APRA's Prudential Standard CPS 230 does not regulate your Terraform modules. It regulates your ability to manage operational risk through controls, monitoring, and remediation; maintain critical operations through disruption within defined tolerance; and manage risks arising from service providers.
"Move fast and break things" is not a mismatch in banking. It is a category error. The thing you are building is not a platform demo. It is part of the system that must keep running when conditions are hostile.
Hyperscalers provide excellent primitives. But the primitives are not the product in a bank. The product is operational resilience: the demonstrated ability to keep critical operations running in the real world, under stress, while meeting prudential obligations.
A reference architecture does not show up to a supervisory conversation. A landing zone does not write your incident notification to the regulator. A framework does not carry your accountability when customers cannot access their money.
So what does work?
A multi-tier landing zone where the platform tier owns the guardrails (encryption policy, network segmentation, identity boundaries), the tenant tier manages shared resources per business domain (subscriptions, quotas, observability accounts), and the application tier runs workloads. Each tier has its own identity boundaries, its own Terraform state, its own blast radius. The platform team controls the invariants—making safe defaults the path of least resistance and unsafe choices structurally difficult.
That is not a hyperscaler best practice. That is prudential engineering: encoding governance into architecture so that doing the right thing is easier than doing the wrong thing.
Figure 1: Automated cloud onboarding pipeline. Every workload passes through compliance pre-checks, policy-as-code validation, and SRE readiness gates before going live.
CPS 230 is explicit about who owns this: the Board is ultimately accountable for operational risk management, including business continuity and the management of service provider arrangements.
Cloud vendors do not own your accountability. Your bank does.
Under CPS 230, a regulated entity must define and maintain a register of critical operations and set tolerance levels for each, covering maximum disruption time, maximum data loss, and minimum service levels during disruption.
For authorised deposit-taking institutions, APRA provides a minimum baseline of what must be treated as critical: payments, settlements, clearing, deposit-taking and related core operations, customer enquiries, and the systems that support them.
This is why banking cloud architecture is fundamentally different. It cannot be designed around what is elegant. It has to be designed around what is tolerable.
The platform itself must encode this. Pre-built blueprints that bundle authentication, secrets management, observability, and backup configuration into a single deployable unit. A team building a data pipeline or an AI inference service inherits resilience by default, not by remembering to add it. Policy-as-code enforces immutable constraints: deny public network access to data stores, require customer-managed encryption keys, prevent accidental deletion of stateful resources through tag-driven deny-action policies. These are not suggestions in a wiki. They are guardrails that block non-compliant deployments at plan time.
Figure 2: Multi-tier IaC architecture. Platform, tenant, and application tiers each maintain isolated state and identity boundaries. A centralised module registry and configuration store enforce consistency across every deployment.
If you cannot express your architecture decision in terms of tolerance, you do not have a resilience story. You have a set of preferences.
CPS 230 does not stop at defining tolerance. It demands a credible business continuity plan that describes how the entity will maintain critical operations within tolerance levels through disruptions, including disaster recovery planning for critical information assets.
And it demands you test it. Systematically, across critical operations, including an annual exercise across "severe but plausible" scenarios. Those scenarios must include disruptions involving material service providers and contingency arrangements.
This is where most cloud programs in regulated environments quietly fail. Not because they cannot build, but because they cannot prove they can hold.
The gap is almost always the same: observability treated as a nice-to-have rather than a control. You need formal SLO definitions for every service, SRE checklists for every onboarded application, recurring reliability reviews with application owners, and a capacity planning process that runs monthly rather than reactively. Diagnostic logs, audit logs, and metrics from every resource must be shipped to centralised analytics by policy, not by team choice.
CPS 234 reinforces this from the information security angle: security controls must be tested with frequency commensurate to risk, and that includes controls operated by or at third parties. When your cloud provider is the control operator, you still own the assurance obligation.
In startups, resilience is aspirational. In banks, resilience is rehearsed, evidenced, and owned.
A bank's cloud incident response is different because the accountability timeline extends beyond internal stakeholders.
CPS 230 requires notification to APRA within 72 hours after becoming aware of operational risk incidents likely to have material impact, and within 24 hours after a disruption to a critical operation outside tolerance. CPS 234 adds a parallel obligation: material information security incidents, including those at cloud providers, must be reported to APRA within 72 hours.
That alone should change how cloud leaders think about observability, incident classification, and runbooks.
Consider what that 24-hour clock actually demands:
L1 support: 24x7 eyes-on-glass monitoring, immediate alerting on P1 indicators
L2 support: Technical escalation within 15 minutes of P1 classification
L3 support: Deep platform engineering response from vendor and internal teams
Vendor coordination: Pre-mapped critical-severity procedures with cloud provider incident teams
Executive escalation: Pre-coordinated contacts and communication chains
Documentation: Runbooks drilled before the incident starts, not during
All of this documented and rehearsed before the incident starts. Not during.
In a bank, the difference between a "degraded service" and a "tolerance breach" is not semantics. It is governance. It is regulator engagement. It is executive response posture.
If there is a single reason cloud in a bank feels different from cloud everywhere else, it is this: cloud is not a vendor. It is a chain of dependencies.
CPS 230 requires a formal service provider management policy, a maintained register of material service providers, and explicit management of risk arising not only from direct providers but also from fourth parties—the providers your providers rely on.
The standard sets a high bar for material arrangements: formal legally binding agreements with defined service levels, data ownership and control provisions, audit access, subcontractor transparency, and termination rights. It also requires contractual provisions that support APRA access to information and the ability for APRA to conduct on-site visits to the provider.
This challenges the simplified version of "outsourcing to cloud." You do not outsource accountability. You outsource execution and then govern it as if it is yours, because under the standard, it is.
CPS 230 makes it explicit: an entity must be able to execute its business continuity plan and conduct an orderly exit from a material arrangement if needed.
Best practice alone does not cover the governance and exit mechanics that make a cloud strategy survivable.
In many industries, governance is treated as overhead. A brake. Something you tolerate so teams can get back to building.
In banking, governance is the delivery engine. It is how you scale safe change without compounding risk. Get this wrong and you do not just slow down. You compound exposure with every release.
Change management in a regulated environment looks like this: every production change requires an implementation plan, peer review, technical post-implementation verification, and business post-implementation verification from the impacted customer. Risk assessment determines lead time:
Low-risk changes (prior successful precedent): 3 business days lead time
Moderate-risk changes: 5 business days lead time
High-risk changes: 9 business days lead time
Emergency changes: Bypass lead time but not accountability—require post-implementation review
Where does velocity come from? Standard changes. The repeatable, low-risk work that makes up the bulk of platform operations. Pre-approved through templated workflows, many fully automated through CI/CD pipelines. This is the insight most people miss: you do not get speed by relaxing governance. You get speed by investing in automation that satisfies governance at machine speed.
CPS 230 requires internal controls that are designed and operating effectively, monitored and tested with frequency commensurate to risk, and remediated with clear accountabilities and root cause focus.
Then layer on a weekly operational governance cadence:
Monday: Change review and incident SLA review
Weekly: Operational metrics and escalation monitoring
Fortnightly: Problem management and compliance posture checks
Monthly: Capacity and cost reviews
That rhythm is what separates a platform that is operated from one that is merely deployed.
The winning cloud operating model in a bank does not look like a consumer product platform. It looks like a regulated critical service: paved roads where safe defaults are easier than bespoke cleverness, standardised patterns tied to critical operations and tolerance, change that is repeatable and auditable, and resilience that is tested rather than assumed.
Everything described above creates operational discipline. But discipline alone has a ceiling. If every control depends on human execution, you cap at human speed and human consistency. CPS 230 does not just require controls. It requires controls that are operating effectively. Effectiveness at scale demands automation.
This is where modern DevSecOps, AIOps, and value stream automation stop being buzzwords and start being the engineering answer to prudential expectations.
Figure 3: DevSecOps pipeline for regulated environments. Security scanning and policy-as-code gates are pipeline stages, not manual review steps. Change records, attestation, and post-implementation verification are automated end-to-end.
Start with the development pipeline. A mature DevSecOps practice shifts security left: vulnerability scanning runs on every commit, policy-as-code gates reject non-compliant infrastructure at plan time, and automated compliance checks execute as pipeline stages rather than manual review steps. Security is not a gate at the end of delivery. It is woven into every merge request. When a developer provisions a new data store, the pipeline validates encryption configuration, network access rules, and tagging compliance before a single resource is created. That is not overhead. That is a control operating effectively, every time, without human variability.
Value stream automation takes this further: end-to-end from code commit to production with full auditability. Automated change record creation tied to pipeline execution. Automated testing attestation. Automated technical post-implementation verification. The nine-day lead time for high-risk changes stays. It should. But standard changes, the bulk of platform operations, flow through with complete governance traceability and zero manual overhead. You do not choose between velocity and compliance. You engineer both into the same pipeline.
Figure 4: Proactive operational automation. Continuous detection feeds intelligent analysis, which triggers automated remediation. A governance feedback loop ensures incident classification, SLO tracking, and regulatory evidence generation close the cycle.
Then there is AIOps, and this is where operations shifts from reactive to genuinely proactive. Anomaly detection across telemetry that surfaces degradation patterns before they become customer-facing incidents. Predictive capacity management that replaces manual monthly reviews with continuous forecasting. Noise reduction in alerting so that the 2:17am call is a real signal, not the third false positive of the week. Pattern recognition across incident data that identifies systemic weaknesses before they become tolerance breaches. The 24-hour APRA notification clock becomes less frightening when your platform is telling you something is wrong before your customers are.
AI is also changing the development lifecycle itself, and in regulated environments this demands deliberate caution. AI-assisted code review catching security vulnerabilities before they reach a pull request. Infrastructure-as-code validation flagging drift between declared and actual state. Automated generation of deployment runbooks. These accelerate engineering velocity meaningfully. But the guardrails matter. AI outputs in a regulated context require human verification. Explainability is non-negotiable: an auditor needs to understand why a change was approved, and "the model recommended it" is not a sufficient answer. The right posture is AI-assisted, not AI-autonomous. CPS 230 accountability does not transfer to an algorithm.
The real prize is the shift in operating posture. From meeting CPS 230 as a periodic compliance exercise to operating with its intent: genuine, continuous, demonstrable operational resilience. Automated orphan resource detection reducing cost exposure before it compounds. Continuous compliance scanning replacing periodic manual audits. Drift detection alerting when infrastructure deviates from its declared state. Proactive operational engineering does not replace the governance discipline described above. It is the mechanism that makes that discipline sustainable at scale, without burning out the teams who carry it.
The banks that treat DevSecOps and AIOps as engineering disciplines rather than vendor slide decks will be the ones that meet prudential expectations and still have capacity left to build.
CPS 230 commenced on 1 July 2025, with a transition window for pre-existing service provider contractual arrangements running until renewal or 1 July 2026, whichever comes first.
This standard is part of a broader regulatory consolidation: CPS 230 revokes older standards including CPS 232 (Business Continuity Management) as the newer resilience regime takes effect.
For executives in regulated financial services, this is not optional uplift. It is the new baseline.
These are not audit questions. They are leadership questions. The kind that reveal whether your cloud strategy is built for the operating reality of a regulated institution.
What are your critical operations, and what are your tolerances? Maximum disruption time, maximum data loss, minimum service level. If you cannot answer with specifics, your resilience story is incomplete.
Can you demonstrate, through testing, that you can maintain those operations within tolerance under severe scenarios? Not a tabletop exercise. A real test, including provider failure scenarios, run at least annually.
Do you have the telemetry and operating discipline to detect and declare a tolerance breach fast enough to meet your notification obligations? Twenty-four hours from disruption to regulator notification is not a lot of time when your detection depends on a third party.
Do your material service provider arrangements meet prudential expectations? Contracts, monitoring, fourth-party risk visibility, audit access, and APRA access rights. Not just "we signed an enterprise agreement."
Are your DevSecOps pipelines enforcing compliance as code, or is compliance still a manual checkpoint at the end of delivery? If your security and governance controls depend on a human remembering to run them, they are not operating effectively in the way CPS 230 requires.
If a critical provider fails, do you have a credible continuity path and an orderly exit path? Or just optimism?
In a startup, cloud leadership is measured by how fast you can ship.
In a bank, cloud leadership is measured by how well the system holds when it matters most. When vendors fail. When disruptions cascade. When tolerance is threatened. When accountability is real.
That is why cloud in a bank is nothing like cloud anywhere else. Not because banks resist change, but because banks are in the business of trust. And trust must be engineered, governed, and proven.
The regulatory references in this article are drawn from APRA Prudential Standards CPS 230 (Operational Risk Management) and CPS 234 (Information Security), both publicly available at apra.gov.au.
