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 with three years under my belt building high performance infrastructure for fintech companies. I've led teams that built production trading engines processing over 15,000 orders per second at under 500 microseconds of latency. I'm based in Auckland at the moment, on a Partner of a Student Work Visa, and I'm on the hunt for cloud engineering and DevOps roles.

When I joined ZK Frames, we were a small crew with a big ambition: build a high frequency trading engine that could keep pace with the world's fastest markets. We had to process thousands of orders every second, keep latency under half a millisecond, and make sure every single transaction was recorded durably, all while moving at startup speed.

Over the following eighteen months, I led a team of five engineers to rebuild the system from the ground up. Along the way we learned some hard earned lessons about what it actually takes to build secure, scalable cloud architecture for fintech in this part of the world.

Here's what I wish someone had told us when we started.

What you will take away from this

Security is not a feature you bolt on later. It has to be baked into every layer from day one. Fintech systems handle sensitive financial data and have to comply with the Privacy Act 2020, AML/CFT obligations, and RBNZ cyber resilience guidance.
Scalability is about design, not just infrastructure. Your architecture needs to cope with predictable workloads and sudden spikes alike. Design for scale from the start and you won't be ripping things out down the track.
Compliance needs to sit inside the architecture, not beside it. Audit logs, encryption, and access controls should be part of your infrastructure, not an afterthought. The regulators will ask.
Cost control matters from day one. Fintech startups need to balance innovation with actually staying in business. Cloud bills can spiral fast if nobody's watching them.
The AWS Well Architected Framework is your blueprint, and the Financial Services Industry Lens gives you the specialised guidance you need for regulated workloads.

Why fintech cloud architecture is different here

Fintech systems are not standard web apps. They handle the most sensitive data going, personal identification details, transaction records, account balances. They sit under intense regulatory scrutiny. Traffic is unpredictable, with volumes spiking during market hours or promotional pushes. And they need to be fast and available, always.

New Zealand financial institutions operate in one of the most demanding cloud compliance environments around. 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. In particular, the RBNZ 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 see outsourcing as something that automatically weakens the financial system. If anything, it reckons outsourcing increases the system's efficiency. But organisations stay responsible for personal information even when it's handled by outside providers on their behalf, IT providers, cloud services, payroll providers, payment processors, the lot. Your business is on the hook for a privacy breach committed by your cloud storage provider too. Under the Privacy Act 2020, every New Zealand business, no matter how small, 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 if a breach was not technically "your fault", you can still carry responsibility from a compliance standpoint, because your organisation 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 put to bed one of the most fundamental questions in NZ financial services: data residency. The region's three availability zone model delivers a serious amount of availability, security, redundancy and fault tolerance. Single digit millisecond latency means real time processing is finally viable here, real time financial trading included. It is a NZ$7.5 billion investment, forecast to add NZ$10.8 billion to our GDP over fifteen years and create around 1,000 jobs. Industry names are already on board as launch customers, Kiwibank among them.

The AWS NZ region brings four advantages that just were not there when our data sat offshore: built in security and resilience, access to constant innovation, network speed that opens up new kinds of services, and renewable energy from day one. The region offers secure cloud infrastructure trusted by millions of customers, including security sensitive organisations across government, healthcare, and financial services.

For the first time, NZ organisations can run applications and store data locally while tapping into the same 200 plus AWS services that power the world's most innovative companies, with hundreds of new features added every year.

Data sovereignty is not just a compliance checkbox anymore though, it's a design constraint. 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 one event knocking out availability, yet close enough for business continuity setups that need synchronous replication, fast failover, and low latency.

The security pillar: building a bank grade foundation

Security by design

Security has to sit inside every layer of your architecture, not get added on at the end. The AWS Well Architected Framework helps you weigh up the pros and cons of decisions you make while building on AWS. It gives you a consistent way to measure your architecture against best practice and spot where you can improve. Well architected systems genuinely lift your security, reliability, and odds of business success. The Financial Services Industry Lens focuses on designing, deploying, and architecting financial services workloads that support resiliency, security, cost savings, and operational performance, in line with the risk and control objectives you set, including those tied to the regulatory requirements of your supervisory authorities.

The Lens sets out best practice for security, data privacy, and resiliency, built from AWS's experience working with financial institutions around the world. It gives technology teams guardrails they can implement and use with confidence, and it walks through how to build transparency and auditability into your AWS environment.

In January 2026, the AWS Well Architected Financial Services Industry Lens was updated with comprehensive guidance for generative AI and agentic AI workloads. That update gives financial services organisations practical guidance on designing, deploying, and running AI workloads securely and efficiently, helping technology and risk leaders think through how to build AI systems that are secure, reliable, and regulator ready from day one.

Real world example: Group IB has picked up the AWS Financial Software Competency designation, covering its work with banking, insurance, and payments customers. Earning that competency meant going through a rigorous 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. Group IB also had to show proven success through customer case studies in financial services, with measurable outcomes in predictive fraud prevention, and independent third party auditors assessed the performance, reliability, and security of its solutions against the standards financial institutions expect in highly regulated environments. That is the bar we should all be aiming for.

Network security

Use a segmented network layout. Put critical services in their own subnets and expose only what needs to be public. Keep databases and internal services on private networks, with public facing load balancers or gateways handling the user facing traffic. Deploy solid VPC architecture, with public and private subnets, network ACLs, and security groups doing their job.

Real world example: ASB's partnership with POLi shows security by design in practice. With POLi using ASB's open banking APIs, customers can use POLi as a payment method without handing over their username and password. Authentication and payment authorisation happen securely inside the ASB mobile banking app, adding another layer of protection when people transact online. Michael Maclean, ASB's Tribe Lead for Everyday Money, put it simply: the partnership is a win for customers, offering greater choice and improved security. It's a good example of how proper API design and network segmentation can remove the need for customers to share credentials at all, which is a fundamental security principle.

Data protection

Encrypt data everywhere, at rest and in transit. Use AES 256 and TLS. Use AWS KMS to manage your encryption keys. Separate your data tiers by classification, core customer PII, transaction records, and account data should default to ap southeast 6. This is not just good practice, it gives you a defensible data map for when the regulator comes asking where your data actually lives.

Real world example: For IMEX Money Transfer, a family run business that has been moving money between New Zealand and Tonga for over twenty years, all important and sensitive data is encrypted to industry standard. 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

Implement role based access control. Turn on multi factor authentication. Use just in time IAM provisioning so people get temporary permissions rather than standing access. Use AWS Organizations Service Control Policies to enforce hard boundaries.

Threat detection and monitoring

Turn on real time threat detection with Amazon GuardDuty, AWS Inspector, and Security Hub. Configure AWS WAF with managed rule sets plus your own custom exceptions. Store secrets in AWS Secrets Manager. Use CloudTrail for compliance auditing.

The RBNZ's Guidance on Cyber Resilience sets out what the Reserve Bank expects from its regulated entities on cyber resilience, and aims to lift awareness and cyber 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.

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

Security testing

Run a proper cloud security assessment programme, combining vulnerability scanning with AWS Inspector for your EC2 workloads, threat modelling built around financial use cases, and hardened security controls across whatever mix of AWS and other clouds you are running.

The scalability pillar: designing for growth

Microservices architecture

Build for modularity early. Use microservices with domain driven design so different parts of the system can scale independently, and deploy them that way from the start.

Real world example: Tax Management New Zealand (TMNZ), New Zealand's leading tax payment platform, processes thousands of sensitive financial business tax transactions. It uses DecisionRules to keep decision logic out of the application code entirely, reusing it across its .NET microservices and agentic workflows so both technical and non technical staff share one auditable source of truth for business rules. It is a neat example of microservices architecture built for scalability and compliance at the same time.

Container orchestration

Use Kubernetes for orchestration. Build an EKS based internal developer platform. Design for multi region deployment. The AWS Well Architected Framework pushes you toward systems that anticipate failure and scale without constant rewrites.

Real world example: IMEX Money Transfer configured a Kubernetes cluster that auto scales to meet demand and lift reliability when needed, using Amazon Elastic Kubernetes Service for the job. Database workloads run on the serverless Amazon Aurora service, and peaky work like PDF generation gets offloaded to AWS Lambda and queued through Amazon SQS. It is a good balance between performance and cost, scaling up and down with demand and making the most of AWS's elasticity. They run infrastructure as code with Terraform, deployed across multiple availability zones for redundancy, and all sensitive data is encrypted to industry standard.

API first design

Build API first stacks, with the API gateway acting as the entry point, identifying tenant context and routing requests from there. Use event driven architecture for real time transaction processing.

New Zealand's banking sector has moved decisively toward this kind of architecture, with the country's biggest banks expanding their deployment of secure APIs. API driven infrastructure has become the backbone of the nation's open banking ecosystem, and that shift is opening up real opportunity for engineers who understand how to build and secure these APIs.

Real world example: New Zealand's four largest banks have moved to Payment Initiation API v2.3, which supports flexible payments and lasting customer consent for open banking. ASB's partnership with POLi is a good example, letting customers use POLi without sharing their username and password, with authentication and authorisation happening securely inside the ASB app. It shows how API first design can lift security and improve the customer experience at the same time.

Handling traffic spikes

Design systems that expect failure and scale without needing constant rewrites. Use serverless architecture to provision exactly the resources a workload needs, with every component scaling automatically.

The compliance pillar: meeting NZ regulatory requirements

NZ specific regulations

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

Privacy Act 2020: applies to every organisation handling personal information. It sets out how businesses must collect, store, use, and disclose that information. If your cloud provider suffers a breach, your organisation still has to notify. 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 has to 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 that can arise when banks outsource functions to third party providers. Getting the big banks fully compliant with BS11 took considerable work over several years, including around 1,500 engagements with affected banks over the past six years.
FMA guidance: Financial Markets Authority requirements for licensees.

Building compliance into the architecture

Build your audit evidence into the architecture itself. Implement centralised logging and distributed tracing from the start. Every transaction has to be recorded durably and protected against unauthorised changes. Use Amazon CloudTrail and Amazon CloudWatch for monitoring, logging, and auditing.

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

Real world example: TMNZ's approach to compliance is a good one to study. Its platform processes tax pooling transactions that have to comply with the Income Tax Act 2007, the Tax Administration Act 1994, and the AML/CFT Act 2009, all at once. Unlike most fintechs, where compliance sits over the top of the product, TMNZ's core product is inseparable from the 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 lived in code, spreadsheets, or undocumented processes, the result was constrained scalability, rising cost to serve, and no real confidence that the audit trail would hold up. 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 wired into n8n agentic workflows, including through MCP, so AI agents and automation could call the same central rules as the application layer. The intent was simple: one source of truth for rule logic, callable from anywhere in the stack, whether that is a microservice, an automation workflow, or an AI agent. That is what compliance built into architecture actually looks like.

For open banking, the stakes are even higher. 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 land a bit later, with a payment initiation API due by the end of May 2026 and an account information API by the end of November 2026. The arrival of regulated open banking is a genuine step forward for security, consumer control, and innovation. ASB became the first bank in the country to support POLi as part of that shift, having gone live with its open banking API platform in May 2024 and now running six partnerships with different payments and data providers.

Security standards

Aim for ISO/IEC 27001:2022 certification. Get PCI DSS ready for payment processing. The Financial Services Industry Lens gives you best practice for security, data privacy, and resiliency across the board.

Infrastructure as code: automation for compliance and speed

Use Terraform to build your fintech infrastructure. It lets you encode controls as infrastructure code so they can be reviewed, tested, and applied consistently. Infrastructure as code turns compliance from a manual checklist into controls that get reviewed, automated, and continuously checked. Implement automated infrastructure and application deployment, build your controls into the code itself, and aim for a portable, configurable infrastructure as code deployment model.

Real world example: 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. It is a good balance of performance and cost, scaling up and down with demand and squeezing real value out of AWS's elasticity.

At ZK Frames, we used AWS to achieve separation at the network level to satisfy our compliance controls. The Well Architected Framework gave us the blueprint, and the Financial Services Industry Lens gave us the specialised guidance on top.

A broader NZ context: the banking transformation underway

What is happening across New Zealand banking right now is genuinely unusual. Upgrading a bank's core system has been compared to heart surgery, it is tricky in ways that are hard to overstate. Pretty much every major New Zealand bank is in the process of upgrading its core systems, making deep structural changes to modernise and unlock innovation. It is the first time this many of New Zealand's major banks have attempted change at this scale, and unusually, they are all doing it at roughly the same time.

The upgrades are a serious challenge given how old some of these systems are, in some cases with technology components dating back to the 1960s. But there is a real opportunity too. It is not just about agility, resilience, or being digital first, it is also about being able to use technologies like AI properly.

BNZ is spending $400 million over five years replacing its core banking systems, aiming for the flexibility to roll out new products and services faster. Its five year "NextGen" programme is a major undertaking, and BNZ has adopted a cloud first strategy, where all new applications go to the cloud first and legacy applications get migrated away from on premises environments over time. With Dynatrace, BNZ achieved a 94 percent reduction in major incidents over five years and lifted high quality software releases by 58 percent, translating into a better customer experience and real operational efficiencies. Nic Olivier, BNZ's Head of Platforms, described the challenge well: migrating a core banking platform to the cloud was, in his words, akin 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, the cloud native core banking platform, to lead a multi year project of core migration and digital transformation. The partnership will deliver core banking infrastructure through a phased, full platform migration, positioning the bank for future growth and continuing to serve its 180,000 plus customers.

SBS Bank's recent transformation is a good example of the same trend. In February 2026, SBS Bank selected Engine by Starling to upgrade its core banking infrastructure, marking the platform's fourth international market entry. Under the 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 stronger fraud protection through a mobile first experience.

Deloitte New Zealand has been appointed as implementation partner for SBS Bank's core banking transformation. Upgrading to Engine's secure, cloud native platform will let SBS Bank's members benefit from world class digital onboarding, accounts, and smart money management through a new mobile app. Grant Frear, Partner at Deloitte New Zealand, said the firm is proud to support SBS Bank on a significant modernisation journey that will help it deliver exceptional digital experiences while building the operational resilience and agility banking will need going forward.

Kiwibank is also mid way through its own core banking upgrade, with CEO Steve Jurkovich noting that Covid 19 caused a pause and reassessment of the bank's digital strategy, which ultimately led to Kiwibank doubling down on its plans to use the cloud.

Meanwhile New Zealand's open banking ecosystem keeps expanding. Kiwibank became the first NZ bank to enable full open banking for all customer types with permanent, zero fee API access, expanding the addressable market for fintech account aggregation and payment initiation products. The arrival of regulated open banking really is a significant step forward for security, consumer control, and innovation.

Real world example: Plenty of financial institutions are already using FICO Platform on AWS to drive business outcomes, Westpac NZ among them, one of the country's largest retail banks. Regan Goble, Risk Analytics Senior Manager at Westpac NZ, noted that FICO Platform, which supports transformation at scale on AWS, has let the bank shift from focusing on individual decisions about a customer's account to thinking strategically about how it manages customers across all their accounts and throughout their lifetime with the bank. It is a solid reminder that major NZ banks are not just talking about cloud transformation, they are actually doing it.

What we actually built: real world results

At ZK Frames, we built a trading engine that processes over 15,000 orders per second at under 500 microseconds of latency. To get there, we:

Used C++ with memory pools for predictable performance
Implemented non blocking I/O with Linux epoll
Designed real time data pipelines using TimescaleDB
Deployed on AWS with 99.9 percent uptime
Cut incident response time by 42 percent through better monitoring

These are not theoretical numbers, they are what came out of applying the principles laid out here, day after day, in a live production environment.

Lessons learned along the way

One thing we did not see coming was database contention during peak trading hours. Our initial design assumed steady traffic, but real world usage showed sudden spikes. We fixed it by implementing read replicas and connection pooling, a lesson that now shapes every database design decision we make.

Manual scaling takes time and adds risk. Compliance needs to be built in early, not bolted on later. Cost control matters from the very start.

The RBNZ's approach to cloud outsourcing does not rule cloud out, but it does expect solid risk management, and that reflects the reality that fintech startups have to balance innovation with compliance every step of the way.

Where to from here

Building secure, scalable cloud architecture for fintech is genuinely hard, but it is achievable. By following the AWS Well Architected Framework, embedding security and compliance from day one, and designing for scale, you can build systems that handle millions of transactions reliably.

Financial institutions in New Zealand are operating in one of the most demanding cloud compliance environments around. But with the right architecture, security by design, infrastructure as code, and compliance built in from the start, it is entirely possible to build systems that are both innovative and regulator ready.

Open banking is here. AI tools are being deployed faster than they are being secured. The banks themselves, and the large licensee groups, are going to start asking hard questions of every AI tool in their ecosystem. The weakest link in any data sharing chain is the one that eventually breaks.

Do not let that weakest link be your architecture.

References

I'm Nischal Khanal, an AWS Certified Solutions Architect based in Auckland. I've spent the last three years building high performance fintech infrastructure, leading teams of five engineers, and learning what it takes to build systems that are secure, scalable, and compliant. If you are working on something interesting in fintech, cloud, or DevOps, I would love to connect, reach out on LinkedIn or check out my work at khanalnischal.com.np.