Skip to content

Deployment sequence

Resolves: GAP-D01 — No deployment sequence document.

This document defines the order in which all 149 modules across eight system domains must be deployed. It applies equally to initial greenfield deployments and to re-deployments when modules are updated.

Related: provisioning playbook · module activation matrix

Why sequence matters

Modules have hard runtime dependencies — not just build-time ones. A module that starts before its dependencies are ready will either fail health checks immediately or produce corrupt state that is difficult to untangle later. The constraints are:

  • Infrastructure before application. Every application module assumes that S3 buckets, KMS keys, Kinesis streams, EventBridge buses, Cognito user pools, SSM parameters, and IAM roles already exist. MOD-104 creates all of these. Nothing can run before it.
  • Databases before any service that writes to them. MOD-103 provisions the Neon project and all eight databases with correct roles and PgBouncer pools. Any service that touches a database — which is nearly every module — depends on this.
  • Secrets before services. MOD-045 (secrets and key management) writes the initial secret references into Secrets Manager. Services that pull secrets at startup will fail if MOD-045 has not run. Populate all secrets per the secrets manifest before starting application modules.
  • Observability before workload. MOD-076 provisions the observability platform (metrics, tracing, log routing). Deploy it before application modules so that any startup errors are captured.
  • Core banking before dependent domains. SD01 (Core Banking) provides the account ledger and event bus that SD03 AML, SD04 Payments, and SD05 Credit all consume. Starting those domains before SD01 is ready means their startup event subscriptions will silently miss the first events.
  • KYC before account opening and credit. SD02 issues the KYC verification tokens that SD08 account opening and SD05 credit decisions depend on. Deploying those modules first means the KYC gate cannot be enforced during early testing.
  • AML depends on events flowing from SD01 and SD02. SD03 AML monitoring subscribes to account and transaction events from SD01 and customer risk signals from SD02. These subscriptions must be registered after SD01 and SD02 are deployed, otherwise AML monitoring starts with gaps in its event history.

Phases overview

Phase System domains Gate
Phase 0 — Foundation SD07 (infrastructure modules only) Must complete before any other phase
Phase 1 — Core banking SD01 Phase 0 complete
Phase 2 — Identity & KYC SD02 Phase 0 complete
Phase 3 — AML monitoring SD03 Phase 1 + Phase 2 complete; events flowing
Phase 4 — Payments SD04 Phase 1 complete
Phase 5 — Credit SD05 Phase 1 + Phase 2 complete
Phase 6 — Risk platform SD06 Phase 1 complete
Phase 7 — App layer SD08 All prior phases complete

Phases 1, 2, 4, 5, and 6 can run concurrently with each other once Phase 0 is complete, subject to the constraints noted above. Phase 3 must wait for both Phase 1 and Phase 2. Phase 7 is the last.

Phase 0 — Foundation

Phase 0 runs once for a new environment. For subsequent deployments, only re-run modules in this phase if their source has changed.

Step 0.1 — AWS bootstrap (MOD-104)

Module: MOD-104 (AWS bootstrap), SD07 Data Platform, repo bank-platform

Why first: MOD-104 has no dependencies. It is the only module that can run against a blank AWS account. It provisions every shared infrastructure resource that all other modules rely on:

  • EventBridge buses (one per system domain)
  • S3 buckets (document storage, audit log archive, data lake landing zone)
  • KMS keys (per-domain envelope encryption keys)
  • Kinesis Data Streams (event streaming backbone)
  • Cognito user pools (customer identity, internal identity)
  • IAM roles (per-service least-privilege roles, CI/CD deployment roles)
  • CloudTrail (audit trail — active from first deploy)
  • SSM Parameter Store baseline (environment-level non-secret config)

First-ever run only: Before the first run in a new AWS account, an engineer must authenticate manually:

aws sso login --profile bank-{env}-bootstrap
aws sts assume-role \
  --role-arn arn:aws:iam::{account-id}:role/BankBootstrapRole \
  --role-session-name bootstrap-session

After this first run, all subsequent deployments use the CI/CD IAM roles that MOD-104 created. No further manual credential handling is needed.

Deployment command: 

cd bank-platform && npx sst deploy --stage {env} --filter mod-104-aws-bootstrap

Step 0.2 — Database and analytics bootstrap (parallel)

Once MOD-104 is healthy, run these two in parallel:

MOD-103 — Neon database bootstrap (SD07, bank-platform)

Provisions the Neon project for this environment and creates all eight databases: bank_core, bank_kyc, bank_aml, bank_payments, bank_credit, bank_app, plus the platform and reporting databases. Also configures:

  • Per-database roles (read-write service role, read-only reporting role, migration role)
  • PgBouncer connection pools (transaction pooling for all application databases)
  • Flyway migration pipeline (connected to each repo's /db/migrations/ directory)

After MOD-103 completes, run the baseline schema migrations for each database before application modules start:

flyway -url={neon-connection-string} -locations=filesystem:bank-core/db/migrations migrate
# repeat for bank-kyc, bank-aml, bank-payments, bank-credit, bank-app

MOD-102 — Snowflake configuration (SD07, bank-platform)

Provisions the Snowflake environment: warehouse, database, schema structure, and the replication pipeline from Kinesis into Snowflake. This is the analytics and reporting layer — no application module depends on it at startup, so it can run in parallel with MOD-103 and complete at any time before the data platform pipelines in SD07 start.

Step 0.3 — Secrets and observability (parallel)

Once MOD-104 is complete (MOD-103 does not need to be finished):

MOD-045 — Secrets and key management (SD07, bank-platform)

Configures the secrets management infrastructure: Secrets Manager policies, secret rotation lambdas, KMS key aliases, and the secrets access patterns for each service role. After MOD-045 completes, populate all required secrets per the secrets manifest before proceeding to application modules.

MOD-076 — Observability platform (SD07, bank-platform)

Deploys the centralised observability stack: CloudWatch dashboards, X-Ray tracing config, log group routing, Datadog agent (if enabled), and the alerting configuration. Must be deployed before application modules so that startup events and errors are captured from day one.

Step 0.4 — Database access control (MOD-046)

Dependencies: MOD-103 (databases exist) + MOD-045 (secrets infrastructure exists)

MOD-046 configures DBA access control: Neon branch-level permissions, just-in-time database access via AWS IAM, audit logging of all DBA sessions, and the break-glass procedures for emergency access. This is the last Phase 0 module.

Phase 0 parallelism summary

MOD-104  ──────────────────────────────────────────────────────────►
              ├── MOD-103 ──────────────────────────────────────────►
              │       │
              │       └── (schema migrations)
              │
              ├── MOD-102 ──────────────────────────────────────────►
              │
              ├── MOD-045 ──────────────────────────────────────────►
              │       │
              │       └── (populate secrets)
              │
              └── MOD-076 ──────────────────────────────────────────►
                                                   │
                                   MOD-046 depends on 103 + 045

Phase 1 — Core banking (SD01)

Gate: Phase 0 complete; all secrets populated; schema migrations run on bank_core.

SD01 (Core Banking, bank-core) is the ledger layer. It owns the account object, the transaction record, the balance, and the event bus topology that downstream domains subscribe to. Deploy SD01 modules in internal dependency order:

  1. Account lifecycle modules — account creation, account status management, account closure. No SD01 cross-dependencies; deploy first or in parallel.
  2. Balance and ledger modules — depend on account lifecycle being ready.
  3. Interest and fee engine — depends on balance modules.
  4. Statement generation — depends on balance and transaction history.
  5. Overdraft and limit management — depends on account lifecycle and balance.
  6. Direct debit and recurring payment setup modules (if in SD01 scope) — depend on account lifecycle.

Within each tier, modules with no dependency on each other can deploy in parallel. The CI/CD pipeline (bank-core GitHub Actions workflow) manages this automatically.

Phase completion signal: The bank_core health endpoint returns 200 and the account.created EventBridge event fires successfully on a smoke-test account creation.

Phase 2 — Identity & KYC (SD02)

Gate: Phase 0 complete; bank_kyc migrations run.

SD02 (KYC Platform, bank-kyc) can start as soon as Phase 0 is done — it does not depend on SD01. It depends on Cognito (MOD-104) and the eIDV third-party integrations being configured.

Deploy order within SD02:

  1. Customer identity core — customer record, identity document store, biometric linkage.
  2. eIDV and document verification module — depends on customer identity core; requires GreenID / Frankie One credentials in Secrets Manager.
  3. KYC risk scoring — depends on eIDV results being available.
  4. Sanctions and PEP screening — depends on KYC risk scoring.
  5. KYC lifecycle management — ongoing monitoring, refresh triggers, step-up triggers.

Phase completion signal: A test customer can be created, verified via eIDV, and a KYC-passed token is issued.

Phase 3 — AML monitoring (SD03)

Gate: Phase 1 AND Phase 2 complete; EventBridge subscriptions from SD01 and SD02 are active.

SD03 (AML Monitoring, bank-aml) subscribes to events from both SD01 (transactions, account changes) and SD02 (customer risk updates). It must not be started until both event sources are live — AML rules that look back at historical events during startup will silently miss any events that were emitted before the subscriptions were registered.

Deploy order within SD03:

  1. Transaction monitoring rules engine — the core evaluation module.
  2. Suspicious activity detection — depends on the rules engine.
  3. STR (Suspicious Transaction Report) generation — depends on suspicious activity detection.
  4. Sanctions screening (real-time) — can deploy in parallel with the above once Phase 0 is done; does not need SD01 events.
  5. AML case management — depends on STR generation.
  6. Regulatory reporting pipelines (AUSTRAC, FMA) — depends on all of the above.

Phase completion signal: A synthetic high-value transaction fires the expected AML alert.

Phase 4 — Payments (SD04)

Gate: Phase 1 complete (needs account ledger); payment rail credentials in Secrets Manager.

SD04 (Payments, bank-payments) depends on SD01 for the account and balance objects it posts transactions against. Payment rail connectivity (BPAY, NPP, NZ faster payments, SWIFT) must be configured before payment modules start.

Deploy order within SD04:

  1. Payment instruction core — payment object, validation rules, authorisation check.
  2. Domestic payment rails — BPAY (AU) and NZ faster payments (NZ) modules.
  3. NPP / real-time payments (AU) — depends on payment instruction core and NPP FII being configured.
  4. SWIFT / correspondent banking — optional; deploy only if payments.swift.enabled = true.
  5. Payment scheduling and recurring payments — depends on payment instruction core.
  6. Scam detection and friction layer — depends on payment instruction core; can deploy in parallel with rail modules.
  7. Confirmation of payee (AU NPP CoP) — depends on NPP module.

Phase completion signal: A test payment completes the full rail round-trip in the dev environment (sandbox mode).

Phase 5 — Credit (SD05)

Gate: Phase 1 (account ledger) AND Phase 2 (KYC) complete.

SD05 (Credit, bank-credit) requires both an account to attach the credit facility to (SD01) and a verified KYC status for the applicant (SD02). Credit bureau credentials (Equifax AU, Centrix NZ) must be in Secrets Manager.

Deploy order within SD05:

  1. Credit application intake — captures application data; depends on KYC token from SD02.
  2. Credit bureau integration — calls Equifax / Centrix; requires API credentials.
  3. Credit decision engine — depends on bureau data and internal risk scoring.
  4. Responsible lending disclosure module — always active; no runtime dependency, but must be deployed before any credit product is accessible to customers.
  5. Loan origination and drawdown — depends on decision engine.
  6. Loan servicing and repayment — depends on origination; posts to SD01 ledger.
  7. Collections and arrears management — depends on loan servicing.

Phase completion signal: A test credit application reaches a decision state and the disclosure documents are generated.

Phase 6 — Risk platform (SD06)

Gate: Phase 1 complete; bank_risk_platform migrations run.

SD06 (Risk Platform, bank-risk-platform) provides the cross-domain risk aggregation layer. It consumes events from SD01, SD05, and eventually SD03. It can be deployed in parallel with phases 2–5 as long as Phase 1 is done.

Deploy order within SD06:

  1. Risk data ingestion — subscribes to SD01 events; must be deployed after Phase 1.
  2. Related party exposure monitoring — depends on risk data ingestion.
  3. Concentration risk — depends on risk data ingestion.
  4. Prudential threshold monitoring (OBR, DCS, capital ratios) — depends on risk data; NZ-specific modules gated by feature flag.
  5. Risk reporting — depends on all of the above.

Phase completion signal: The related party exposure dashboard shows correct values for a test account set.

Phase 7 — App layer (SD08)

Gate: All phases 0–6 complete.

SD08 (App, bank-app) is the customer-facing and banker-facing application layer. It orchestrates calls to all other system domains. Nothing in the app layer is safe to deploy until every underlying service it calls is ready — a partial SD08 deployment would expose customers to runtime errors on core flows.

Deploy order within SD08:

  1. Session management and authentication — depends on Cognito (MOD-104) and KYC gates (SD02).
  2. Onboarding flows — account opening, KYC capture, depends on SD02 eIDV and SD01 account creation.
  3. Account dashboard — depends on SD01 balance and statement modules.
  4. Payment initiation flows — depends on SD04 payment instruction core.
  5. Card management (if enabled) — depends on card bureau integration (Cuscal/Monoova credentials).
  6. Loan application flows — depends on SD05 credit application intake.
  7. Notifications and alerts — depends on EventBridge events flowing from SD01–SD06.
  8. Open banking APIs (CDR/NZ consumer data) — deploy last; requires all data sources to be stable.

Phase completion signal: End-to-end smoke test passes: a test customer can log in, view a balance, and initiate a payment.

Modules that can run in parallel within a phase

The following table captures the key parallelism opportunities. Within a phase, all modules listed on the same row can be deployed concurrently.

Phase Parallel group Notes
Phase 0 MOD-102, MOD-103 After MOD-104 only
Phase 0 MOD-045, MOD-076 After MOD-104 only
Phase 1 Account lifecycle modules No SD01 cross-dependencies
Phases 1 + 2 All of Phase 1, all of Phase 2 Independent of each other
Phases 1 + 4 All of Phase 1, all of Phase 4 Phase 4 gate is Phase 1, not Phase 2
Phases 1 + 6 All of Phase 1, all of Phase 6 Phase 6 gate is Phase 1 only
Phases 2 + 4 + 6 Entire phases in parallel After Phase 1 is complete
Phases 2 + 5 Partial: Phase 2 and Phase 5 Phase 5 also needs Phase 1
Phase 3 Only after Phase 1 AND Phase 2 Events from both must be live
Phase 7 App modules with no cross-SD08 dependencies Authentication must come before onboarding

Re-deployment (module updates)

When updating a module after initial deployment:

  • Same sequence, but only changed modules need to re-run. The CI/CD pipeline tracks which modules have changed by comparing the Git SHA of the module's source directory. Unchanged modules are skipped.
  • Infrastructure changes in Phase 0 modules propagate to downstream modules. If MOD-104 changes (e.g. a new KMS key alias), any module that depends on that alias must also be redeployed. The SST dependency graph handles this automatically.
  • Database schema migrations run first. If a module update includes a schema migration, Flyway applies it before the module deploys. Migrations are always forward-only.
  • Zero-downtime deployments. All application modules use blue-green deployment via Lambda aliases. The old version continues to serve traffic until the new version passes health checks.

Rollback

Each module is independently rollback-able:

cd {repo} && npx sst rollback --stage {env} --filter {module-slug}

SST tracks the last-known-good deployment for each module. Rollback restores the Lambda code version and reverts SSM parameters to the previous values. It does not roll back database migrations — if a migration is incompatible with the rolled-back code, a compensating migration must be written.

For a Phase 0 module rollback (rare): coordinate with the engineering lead. Rolling back MOD-104 in an environment with live application modules running against it requires a full maintenance window.

Environment promotion

Code moves through environments in order: local → dev → uat → prod. Each environment is a fully independent deployment. The deployment sequence above applies identically to each environment. There are no shared infrastructure resources between environments.

Secrets and configuration are environment-specific. A secret populated in dev is not automatically available in uat — each environment must be provisioned separately per the secrets manifest and configuration manifest.