Key Takeaways
- Controls in Terraform, not spreadsheets: We encode APRA CPS 234 information security controls and CPS 230 operational resilience requirements directly into Terraform (
VPC Service Controls,CMEKencryption, organisation policies, and immutable audit log sinks). - Sub-second fraud and AML scoring: We replace overnight batch fraud jobs with streaming pipelines on Cloud Pub/Sub, Dataflow, BigQuery, and Vertex AI that score transactions in milliseconds before settlement.
- In-country AI sovereignty: Generative AI and agent workflows run strictly within Google Cloud’s Sydney (
australia-southeast1) and Melbourne (australia-southeast2) regions with Sensitive Data Protection (DLP) masking and zero training on customer data. - Incremental core banking modernisation: Instead of high-risk “big-bang” core replacements, we place an API facade in front of legacy monoliths and strangle capabilities one at a time onto GKE and Cloud Run.
Cloud engineering for regulated Australian finance
Banks, insurers, super funds and FinTechs all end up in the same place. The engineering team knows what it wants to build. The risk committee needs to know what happens when it breaks, who else can see the data, and which third party is now in the critical path. Getting a release out means satisfying both, and most delays we see aren’t technical at all. They’re evidence problems.
That’s the work. We build Google Cloud platforms where the controls are in the Terraform, not in a spreadsheet someone updates before an audit. VPC Service Controls to stop data leaving a perimeter, customer-managed encryption keys so you hold the key material, and audit logs written to a sink nobody on the delivery team can alter. When an assessor asks how you know a control is on, the answer is a plan output rather than a meeting.
Our two founders spent 16 years between them at Google Cloud, and they stay across the architecture on live engagements. Projects are fixed price, with a fixed date, agreed before work starts.
What usually brings people to us
“CPS 230 turned our vendor list into a risk register and we can’t answer it.” Operational risk standards ask you to name your critical operations, the services behind them, and what you’d do if a provider disappeared. Most estates can’t produce that map because nobody ever wrote down which service depends on which. We start by generating it from the infrastructure itself rather than by interviewing people.
“Fraud scoring runs overnight, and the money’s already gone.” Batch fraud detection catches things after settlement, which is useful for reporting and useless for prevention. Moving to sub-second scoring means Pub/Sub, Dataflow and a feature store that can answer questions about an account in single-digit milliseconds. It’s a real re-architecture, not a model swap, and it’s usually the highest-value thing on the list.
“We can’t use AI because the data can’t leave the country.” It can’t, and it doesn’t have to. Vertex AI runs in Sydney and Melbourne. The harder part is the plumbing around it: masking identifiers before a prompt is built, keeping retention at zero, and logging enough that you can reconstruct why a model said what it said. That plumbing is the project.
“The core is COBOL and nobody wants to touch it.” Fair enough. Big-bang core replacements have a poor record and we don’t recommend them. We put a facade in front of the monolith and move one capability at a time, so each step is independently reversible. Slower on paper, and much less likely to end up in an incident review.
“Two environments, double the bill.” Running old and new in parallel during a migration is unavoidable, but the overlap window is where budgets die. Cutting it means sequencing the migration around data gravity instead of around org charts.
Which regulations we actually design against
APRA CPS 234 for information security and CPS 230 for operational risk are the two that shape most architectures. Beyond those we build to the ACSC Essential Eight, and for firms with an offshore footprint, SOC 2 and ISO 27001. If you’re a FinTech under an AFSL rather than an ADI, the bar is different and usually lighter than people assume, so it’s worth scoping before you over-build.
What we build
- APRA CPS 234 and CPS 230 landing zones. Terraform that enforces VPC Service Controls, customer-managed encryption keys and immutable audit logging, with controls mapped to the ACSC Essential Eight.
- Real-time fraud and AML scoring. Pipelines on Pub/Sub, Dataflow and BigQuery that score transactions against fraud models before settlement.
- In-country AI on Vertex AI. Assistants that run only in the Sydney and Melbourne regions, with DLP masking, no external retention and strict access boundaries.
- Core banking modernisation. Strangler fig refactoring that moves capabilities off the monolith one at a time, onto GKE and Cloud Run.
Step-by-Step Engagement Approach
- Step 1: Infrastructure Dependency & Regulatory Gap Mapping — We inspect your live Google Cloud or legacy estate to map critical operations, third-party dependencies, and control gaps against APRA CPS 234, CPS 230, and the ACSC Essential Eight.
- Step 2: Hardened Terraform Landing Zone & Perimeter Lock — We deploy organisation policy constraints, Shared VPC topologies, VPC Service Controls perimeters, Customer-Managed Encryption Keys (CMEK), and locked audit sinks in code.
- Step 3: Incremental Workload & Pipeline Delivery — We migrate capabilities or deploy real-time streaming and sovereign Vertex AI workloads in bounded, reversible increments with automated CI/CD compliance gates.
- Step 4: Continuous Evidence & Handover — We wire continuous posture and detection telemetry into Wiz and Google SecOps so your risk committee and external auditors receive live control evidence rather than manual spreadsheets.
Related work
- Security reviews: APRA CPS 234 reviews, ACSC Essential Eight and SOC 2 readiness.
- Cloud foundations: landing zones, VPC Service Controls and CMEK governance.
- Confirm Control: mobile field risk management with full audit logging.
- Site reliability engineering: resilience engineering aligned with APRA CPS 230.
- All case studies
Questions we get asked
How do your Google Cloud architectures support APRA CPS 234 and CPS 230 compliance?
We write APRA CPS 234 information security controls and CPS 230 operational resilience requirements into Terraform: organisation policy guardrails, VPC Service Controls, CMEK encryption, automated multi-region failover, and immutable audit trails.
Can we deploy generative AI agents without exposing sensitive financial data outside Australia?
Yes. We deploy Vertex AI and Gemini models pinned to Australian Google Cloud regions (Sydney and Melbourne) inside VPC Service Controls perimeters. Customer prompts and data are not used for model training.
How do you handle real-time fraud and transaction anomaly detection on Google Cloud?
We stream transaction events through Pub/Sub and Dataflow into BigQuery and Vertex AI endpoints for sub-second risk scoring, with alerts fed into your core banking or claims workflows.
Talk to an architect who has done this before.
Bring your current setup and the outcome you need. You will get a view on the approach, the risks and roughly what it costs.
Straight to a senior GCP architect. No SDR, no slide deck.
Not ready to talk? See how we migrated Hapana off AWS →
Or call +61 2 8359 9507 · Hello@aviato.consulting