Building a Secure, Scalable Cloud Architecture for Fintech Startups in Aotearoa New Zealand By Nischal Khanal, AWS Certified Solutions Architect

I'm Nischal, an AWS Certified Solutions Architect based in Auckland, currently on a Partner of a Student Work Visa and looking for cloud engineering and DevOps roles. Over the past three years I've worked on infrastructure for fintech companies, including a production trading system at ZK Frames, a small trading technology team, that processed over 15,000 orders per second at under 500 microseconds of latency.

At ZK Frames I worked alongside four other engineers over about eighteen months to rebuild that system. The brief was straightforward to state and hard to deliver: process thousands of orders every second, keep latency under half a millisecond, and make sure every transaction was recorded durably, all on a startup budget and timeline. Along the way we picked up some practical lessons about what secure, scalable cloud architecture for fintech actually requires in the New Zealand market. This piece sets those out, alongside the regulatory context that shapes them.

Executive summary

Security is not a feature added later. It needs to be built into every architectural layer from the outset. Fintech systems handle sensitive financial data and must comply with the Privacy Act 2020, AML/CFT obligations, and RBNZ cyber resilience guidance.
Scalability is a design property, not just an infrastructure setting. Architecture needs to handle predictable load and sudden spikes without a rebuild.
Compliance is a structural requirement, not a documentation exercise. Audit logs, encryption, and access controls belong inside the infrastructure itself.
Cost control has to start on day one. Cloud spend can grow quickly without active governance.
The AWS Well Architected Framework is the baseline reference, and the Financial Services Industry Lens provides the specialised guidance needed for regulated workloads.

Regulatory and infrastructure context for fintech cloud architecture in New Zealand

Fintech systems differ from standard web applications in a few structural ways. They handle sensitive data, personal identification details, transaction records, account balances. They sit under direct regulatory scrutiny. Traffic is unpredictable, with volumes spiking during market hours or promotional periods. And uptime and latency requirements are typically stricter than for a general consumer application.

New Zealand financial institutions operate under a demanding cloud compliance regime. Financial institutions here are permitted to use cloud services, provided they comply with the relevant legal and regulatory requirements. The Reserve Bank of New Zealand (RBNZ) is the supervisory authority for banks, insurers, and non bank deposit takers. It expects large banks to follow its Outsourcing Policy, BS11, which covers governance, risk management, and monitoring and oversight. BS11 requires the largest banks it covers, ANZ, ASB, BNZ, Kiwibank and Westpac, to keep providing basic banking services and meet liquidity requirements regardless of issues affecting their parent or major outsourcing providers.

The RBNZ does not treat outsourcing as something that automatically weakens the financial system, and takes the view that it can improve system efficiency. But organisations remain responsible for personal information even when it is handled by outside providers on their behalf, IT providers, cloud services, payroll providers, and payment processors included. Your business carries responsibility for a privacy breach committed by your cloud storage provider too. Under the Privacy Act 2020, every New Zealand business, regardless of size, has a legal obligation to notify both the Privacy Commissioner and affected individuals if a breach is reasonably likely to cause harm.

The Privacy Act sets out how businesses must collect, store, use, and disclose personal information. Even where a breach was not technically caused by your own systems, responsibility from a compliance standpoint generally still sits with your organisation, since it collected the data and decided how it would be stored and used. Failing to notify the Privacy Commissioner of a notifiable privacy breach is an offence carrying a fine of up to $10,000.

The opening of the AWS Asia Pacific (New Zealand) Region in Auckland in September 2025 resolved one of the more fundamental open questions in NZ financial services architecture: data residency. The region's three availability zone model provides availability, redundancy, and fault tolerance comparable to other mature AWS regions. Single digit millisecond latency makes real time processing, including real time financial trading, practically viable onshore. It represents a NZ$7.5 billion investment, forecast to add NZ$10.8 billion to New Zealand's GDP over fifteen years and support around 1,000 jobs. Launch customers include Kiwibank, among a wider group of local organisations.

The region brings four practical advantages compared with running workloads offshore: built in security and resilience, access to ongoing service innovation, network speed that supports latency sensitive services, and renewable energy sourcing from day one. It offers infrastructure already trusted by government, healthcare, and financial services customers elsewhere.

For the first time, NZ organisations can run applications and store data locally while still accessing the same broad AWS service catalogue, over 200 services at launch, that supports customers globally.

Data sovereignty is now a design constraint rather than purely a compliance checkbox. Auckland to ap southeast 6 latency sits under five milliseconds, compared with roughly 35 milliseconds to Sydney. The region itself is built from a minimum of three isolated, physically separate availability zones, far enough apart to reduce the risk of a single event affecting availability, yet close enough to support synchronous replication, fast failover, and low latency business continuity design.

Security architecture: controls and design patterns

Security by design principles

Security needs to sit inside every architectural layer rather than being appended at the end. The AWS Well Architected Framework provides a consistent method for evaluating architectural decisions and measuring them against best practice. The Financial Services Industry Lens extends that into designing, deploying, and architecting financial services workloads that support resiliency, security, cost efficiency, and operational performance, aligned to the risk and control objectives set by supervisory authorities.

The Lens sets out best practice for security, data privacy, and resiliency, developed from AWS's experience working with financial institutions internationally. It gives technology teams implementable guardrails and describes how to build transparency and auditability into an AWS environment.

In January 2026, the AWS Well Architected Financial Services Industry Lens was updated with guidance covering generative AI and agentic AI workloads. This gives financial services organisations practical direction on designing, deploying, and operating AI workloads securely, which matters for technology and risk leaders working out how to make AI systems regulator ready from the design stage rather than retrofitting controls afterward.

Group IB has obtained the AWS Financial Software Competency designation, covering its work with banking, insurance, and payments customers. Earning that competency required a validation process including a full review of Group IB's architectures, security controls, and operational practices against the Well Architected Framework and AWS best practice, supported by customer case studies demonstrating measurable outcomes in predictive fraud prevention, and independent third party assessment of the performance, reliability, and security of its solutions against the standards expected in regulated financial environments.

Network segmentation

A segmented network layout keeps critical services in dedicated subnets and exposes only what needs to be public. Databases and internal services sit on private networks, with public facing load balancers or gateways handling user facing traffic. This typically means a VPC architecture with public and private subnets, network ACLs, and security groups enforcing least privilege access between tiers.

ASB's partnership with POLi illustrates security by design in a production context. With POLi using ASB's open banking APIs, customers can use POLi as a payment method without providing their username and password. Authentication and payment authorisation happen inside the ASB mobile banking app instead, adding a layer of protection for online transactions. ASB's Tribe Lead for Everyday Money, Michael Maclean, described the partnership as a win for customers on both choice and security grounds. It demonstrates how API design and network segmentation can remove the need for customers to share credentials with a third party, a core security principle rather than a bolt on control.

Data protection

Data should be encrypted everywhere, at rest and in transit, using AES 256 and TLS, with AWS KMS managing encryption keys. Data tiers should be separated by classification, with core customer PII, transaction records, and account data defaulting to ap southeast 6. This is not only good practice, it produces a defensible data map for regulatory review of where data actually resides.

For IMEX Money Transfer, a business that has processed money transfers between New Zealand and Tonga for over twenty years, sensitive data is encrypted to industry standard throughout. Data held in Amazon Elastic File System and Amazon S3 is encrypted both at rest and in transit, and application data, including PII, stored in Amazon RDS is encrypted using public and private key encryption on a per user basis.

Identity and access management

Role based access control, multi factor authentication, and just in time IAM provisioning, granting temporary rather than standing permissions, form the baseline identity model. AWS Organizations Service Control Policies enforce account level boundaries on top of that.

Threat detection and monitoring

Real time threat detection through Amazon GuardDuty, AWS Inspector, and Security Hub, combined with AWS WAF running managed rule sets plus custom exceptions, forms the detection layer. Secrets belong in AWS Secrets Manager rather than configuration files, and CloudTrail provides the audit trail needed for compliance reporting.

The RBNZ's Guidance on Cyber Resilience sets out the Reserve Bank's expectations for regulated entities on cyber resilience, aimed at lifting awareness and resilience across the financial sector, particularly at board and senior management level. It applies to every entity the RBNZ regulates, including registered banks, licensed non bank deposit takers, licensed insurers, and designated financial market infrastructures, and it draws on established frameworks such as the New Zealand Information Security Manual for entities needing more detailed technical guidance.

The AWS RBNZ Guidance on Cyber Resilience Workbook helps customers map their AWS controls against that guidance, covering both security in the cloud, mapping RBNZ practices to the five pillars of the Well Architected Framework, and security of the cloud, mapping RBNZ practices to AWS's compliance program. The workbook is available through AWS Artifact, AWS's self service portal for on demand access to compliance reports.

Security testing and assurance

A cloud security assessment programme should combine vulnerability scanning, AWS Inspector against EC2 workloads, threat modelling built around financial use cases, and hardened security controls across whatever mix of cloud providers is in use, reviewed on a recurring rather than one off basis.

Scalability architecture: patterns for growth

Microservices architecture

Building for modularity early, using microservices with domain driven design, allows different parts of a system to scale independently rather than as one monolithic unit.

Tax Management New Zealand (TMNZ), a tax payment platform processing thousands of sensitive financial business tax transactions, uses DecisionRules to keep decision logic out of application code, reusing it across its .NET microservices and agentic workflows so technical and non technical staff share one auditable source of truth for business rules. It is a useful reference point for microservices architecture designed for scalability and compliance together, rather than treating the two as separate concerns.

Container orchestration

Kubernetes handles orchestration, typically via an EKS based internal developer platform designed for multi region deployment. The AWS Well Architected Framework's underlying principle here is designing systems that anticipate failure and scale without requiring constant rewrites.

IMEX Money Transfer configured a Kubernetes cluster that auto scales to meet demand, using Amazon Elastic Kubernetes Service. Database workloads run on the serverless Amazon Aurora service, and peaky workloads such as PDF generation are offloaded to AWS Lambda and queued through Amazon SQS, balancing performance against cost by scaling with actual demand. Infrastructure is deployed as code with Terraform across multiple availability zones for redundancy, with sensitive data encrypted to industry standard.

API first design

An API first stack uses the API gateway as the entry point, identifying tenant context and routing requests from there, with event driven architecture supporting real time transaction processing.

New Zealand's banking sector has moved toward this model at pace, with the country's largest banks expanding their deployment of secure APIs. API driven infrastructure is now the backbone of the national open banking ecosystem, which is creating demand for engineers who can build and secure these APIs specifically.

New Zealand's four largest banks have moved to Payment Initiation API v2.3, supporting flexible payments and lasting customer consent for open banking. ASB's partnership with POLi is a relevant reference case, allowing customers to use POLi without sharing their username and password, with authentication and authorisation happening inside the ASB app. It demonstrates how API first design can improve both security posture and customer experience in the same implementation.

Handling variable and peak load

Systems should be designed to anticipate failure and scale without requiring constant rewrites. Serverless architecture provisions the resources a workload actually needs, and every component should scale automatically rather than relying on manual intervention during load events.

Compliance architecture: New Zealand regulatory requirements

New Zealand regulatory framework

New Zealand financial services operate under a fairly comprehensive regulatory framework:

Privacy Act 2020: applies to every organisation handling personal information, setting out how businesses must collect, store, use, and disclose it. If a cloud provider suffers a breach, the organisation still carries the notification obligation. Failing to notify the Privacy Commissioner of a notifiable privacy breach is an offence with a fine of up to $10,000.
AML/CFT obligations: anti money laundering and counter terrorism financing requirements. Under Section 57 of the Anti Money Laundering and Countering Financing of Terrorism Act 2009, every reporting entity must establish, implement, and maintain a written AML/CFT programme.
Reserve Bank of New Zealand prudential expectations: applies to registered banks, insurers, and non bank deposit takers. The RBNZ expects large banks to follow the Outsourcing Policy, BS11, designed to manage the risks arising when banks outsource functions to third party providers. Getting the major banks fully compliant with BS11 required considerable work over several years, including around 1,500 engagements with affected banks over the past six years.
FMA guidance: Financial Markets Authority requirements applicable to licensees.

Building compliance into the architecture

Audit evidence should be built into the architecture itself, with centralised logging and distributed tracing implemented from the start. Every transaction needs to be recorded durably and protected against unauthorised changes, typically via Amazon CloudTrail and Amazon CloudWatch for monitoring, logging, and auditing.

Financial institutions using or planning to use AWS services should work through a defined process: assess the purpose of the workload and the categories of data involved, evaluate how material or critical that workload is, review the AWS Shared Responsibility Model and map responsibilities service by service, and use AWS Artifact to obtain AWS's own audit reports.

TMNZ's approach to compliance is a useful case reference here. Its platform processes tax pooling transactions that must comply with the Income Tax Act 2007, the Tax Administration Act 1994, and the AML/CFT Act 2009 simultaneously. Unlike many fintechs, where compliance sits as a layer over the product, TMNZ's core product is inseparable from its regulatory framework: every transaction is auditable against primary legislation, and every rule governing pricing, billing, and payment matching has to trace back to its legislative basis. When those rules previously lived in code, spreadsheets, or undocumented processes, the result was constrained scalability, rising cost to serve, and limited confidence that the audit trail would hold up under scrutiny. DecisionRules was deployed self hosted on TMNZ's Azure environment with SSO and database integration, connected to .NET microservices through API calls to the DecisionRules solver, and integrated into n8n agentic workflows, including through MCP, so AI agents and automation can call the same central rules as the application layer. The underlying design goal was a single source of truth for rule logic, callable from any point in the stack, whether that is a microservice, an automation workflow, or an AI agent.

Open banking raises the stakes further. Open banking rules are already in force for the big four banks, ANZ, ASB, BNZ, and Westpac have had to comply since 1 December 2025. Kiwibank's regulatory deadlines fall later, with a payment initiation API due by the end of May 2026 and an account information API by the end of November 2026. ASB became the first bank in the country to support POLi under this regime, having gone live with its open banking API platform in May 2024 and now running six partnerships with different payments and data providers.

Security certification standards

ISO/IEC 27001:2022 certification and PCI DSS readiness for payment processing form the external assurance layer. The Financial Services Industry Lens provides best practice guidance for security, data privacy, and resiliency that underpins both.

Infrastructure as code: automation for compliance and speed

Terraform is the standard tool for building fintech infrastructure as code, encoding controls so they can be reviewed, tested, and applied consistently. This converts compliance from a manual checklist into controls that get reviewed, automated, and continuously checked. Automated infrastructure and application deployment, controls embedded in code, and a portable, configurable infrastructure as code deployment model are the practical outcomes of this approach.

IMEX Money Transfer runs infrastructure as code with Terraform, deployed across multiple availability zones for redundancy, with a Kubernetes cluster configured to auto scale as demand shifts, balancing performance and cost against AWS's underlying elasticity.

At ZK Frames, network level separation was used to satisfy compliance controls, with the Well Architected Framework providing the general blueprint and the Financial Services Industry Lens providing the specialised guidance on top of it.

Industry context: core banking modernisation in New Zealand

Core banking upgrades across New Zealand are underway at a scale and pace not seen before. Most major New Zealand banks are in the process of upgrading their core systems, making structural changes intended to modernise and unlock further innovation. It is the first time this many of the country's major banks have attempted change of this scale concurrently.

The scope of the challenge reflects the age of some of these systems, in certain cases with technology components dating back to the 1960s. The opportunity runs in parallel: beyond agility and resilience, modernised core systems are also a prerequisite for using AI capabilities effectively at scale.

BNZ is spending $400 million over five years replacing its core banking systems, aiming for greater flexibility to roll out new products and services. Its five year "NextGen" programme includes a cloud first strategy, where new applications are deployed to the cloud first and legacy applications are migrated away from on premises environments over time. With Dynatrace, BNZ reports a 94 percent reduction in major incidents over five years and a 58 percent increase in high quality software releases. BNZ's Head of Platforms, Nic Olivier, described migrating the core banking platform to the cloud as comparable to performing open heart surgery while sprinting.

The Co operative Bank, the only customer owned bank in New Zealand that shares profits with its customers, has become the first bank in the country to select 10x Banking, a cloud native core banking platform, for a multi year core migration and digital transformation project, delivered through a phased full platform migration and intended to support its 180,000 plus customers going forward.

SBS Bank's core banking transformation is a further example of the same trend. In February 2026, SBS Bank selected Engine by Starling to upgrade its core banking infrastructure, marking that platform's fourth international market entry. Under a ten year agreement, the New Zealand owned mutual will migrate its core systems to Engine's cloud native platform, supporting streamlined onboarding, real time card controls, spending insights, and fraud protection through a mobile first experience. Deloitte New Zealand has been appointed as implementation partner for the programme.

Kiwibank is also mid way through its own core banking upgrade. CEO Steve Jurkovich has noted that Covid 19 caused a pause and reassessment of the bank's digital strategy, which ultimately led to a firmer commitment to cloud based systems.

New Zealand's open banking ecosystem continues to expand alongside these core system upgrades. Kiwibank became the first NZ bank to enable full open banking for all customer types with permanent, zero fee API access, extending the addressable market for fintech account aggregation and payment initiation products.

Financial institutions already using FICO Platform on AWS to drive business outcomes include Westpac NZ, one of the country's largest retail banks. Westpac NZ's Risk Analytics Senior Manager, Regan Goble, has noted that FICO Platform, supporting transformation at scale on AWS, has allowed the bank to shift from managing individual account level decisions toward a more strategic view of customer relationships across their full account portfolio and lifetime with the bank.

Production system results

The trading system built at ZK Frames processed over 15,000 orders per second at under 500 microseconds of latency. The approach that got it there included:

C++ with memory pools for predictable performance
Non blocking I/O using Linux epoll
Real time data pipelines built on TimescaleDB
Deployment on AWS maintaining 99.9 percent uptime
A 42 percent reduction in incident response time following improved monitoring

These figures reflect a specific system built for a specific workload, order matching under strict latency constraints, rather than a general benchmark for fintech infrastructure. They are included here as a concrete data point for what the design choices in this piece can produce in practice.

Operational lessons

Database contention during peak trading hours was not something the initial design accounted for. The original assumption was steady traffic; real world usage showed sudden spikes instead. Read replicas and connection pooling addressed this, and that experience now informs database design decisions more broadly.

Manual scaling introduces both delay and risk. Compliance requirements are cheaper to build in early than to retrofit. Cost control needs active governance from the start rather than periodic review after spend has already grown.

The RBNZ's approach to cloud outsourcing does not prohibit it, but it does expect robust risk management, which reflects the underlying tension fintech startups have to manage between moving quickly and meeting compliance obligations.

Conclusion

Building secure, scalable cloud architecture for fintech is achievable, though not straightforward. Following the AWS Well Architected Framework, embedding security and compliance from the outset, and designing explicitly for scale are the practical mechanisms for building systems that can handle high transaction volumes reliably.

Financial institutions in New Zealand operate in a demanding cloud compliance environment. With the right architecture, security by design, infrastructure as code, and compliance built in from the start, it is possible to build systems that are both innovative and regulator ready.

Open banking is now in force. AI tools are being deployed faster than they are being secured in many organisations, and banks and licensee groups are likely to start asking more detailed questions of every AI tool operating in their ecosystem. In any data sharing chain, the weakest link is the one that eventually causes a failure. Architecture is one of the more controllable variables in avoiding that outcome.

References

I'm Nischal Khanal, an AWS Certified Solutions Architect based in Auckland, working on fintech infrastructure, cloud architecture, and DevOps. If you are working on something in fintech, cloud, or DevOps, feel free to get in touch, on LinkedIn or via khanalnischal.com.np.