Delivery sequence¶
Five phases. Each phase ends with a capability milestone — something demonstrable and testable end-to-end. No phase begins until the previous phase gate passes.
The dependency graph in the module register is the authoritative ordering constraint within each phase. The phase structure below reflects macro sequencing; within a phase, individual modules can be built in parallel where their dependencies allow.
Phase 0 — Bootstrap¶
Mission: Platform infrastructure operational, observable, and secure. No business module can be deployed until this phase is complete.
Capability milestone: A developer can securely connect to all platform services with full observability, structured secret access, and a working CI/CD pipeline.
Modules¶
| Module | System | Description |
|---|---|---|
| MOD-104 | SD07 | AWS shared infrastructure — the absolute root of the dependency tree |
| MOD-076 | SD07 | Observability platform |
| MOD-045 | SD07 | Secrets management and rotation |
| MOD-103 | SD07 | Neon database platform bootstrap |
| MOD-102 | SD07 | Snowflake account configuration and governance |
| MOD-046 | SD07 | Privileged access management |
Phase gate¶
- CI/CD pipeline runs end-to-end for a trivial "hello world" Lambda and deploys to dev
- Secrets Manager, Neon connection, and Snowflake connection all accessible from Lambda
- Structured log entry emitted and visible in MOD-076 dashboard
- PAM session opens, records, and closes with full audit trail
Phase 1 — Ledger and identity¶
Mission: A verified customer can be onboarded, have an account opened, and have funds posted to it. The regulatory minimum to hold customer funds.
Capability milestone: End-to-end demo: customer onboarding (eIDV → CDD tier → account open → balance posting), visible in back-office and observable in Snowflake.
Modules¶
| Module | System | Description |
|---|---|---|
| MOD-044 | SD07 | JWT role-based access control |
| MOD-042 | SD07 | CDC pipeline — Neon → Snowflake |
| MOD-047 | SD07 | Agent action logger |
| MOD-068 | SD08 | Authentication and session management |
| MOD-009 | SD02 | eIDV and document verification |
| MOD-010 | SD02 | CDD tier assignment |
| MOD-013 | SD02 | Real-time sanctions screener |
| MOD-001 | SD01 | Double-entry posting engine |
| MOD-002 | SD01 | Immutable transaction log |
| MOD-003 | SD01 | Real-time balance engine |
| MOD-004 | SD01 | Multi-currency ledger |
| MOD-007 | SD01 | Account state machine |
Build order within phase: MOD-044 → MOD-068; MOD-009 → MOD-010, MOD-013; MOD-001 → MOD-002 → MOD-003, MOD-004; MOD-007 requires MOD-001 + MOD-003 + MOD-009; MOD-042 requires MOD-001 + MOD-102 + MOD-103.
Phase gate¶
- New customer onboarded: eIDV pass → CDD tier
STANDARDset →banking.customer_relationships.kyc_status = VERIFIED - Account opened in
ACTIVEstate - NZD 100.00 posted: debit and credit legs balanced,
accounts.balanceupdated in same transaction - Sanctions screen run at onboarding:
CLEARresult logged - All events visible in Snowflake via CDC within 60 seconds of each operation
Phase 2 — Transact¶
Mission: A verified customer can send and receive payments with full AML/CFT monitoring active. The regulatory minimum to process customer transactions.
Capability milestone: End-to-end demo: customer initiates a domestic NZD payment → pre-payment validation → posting → AML typology evaluated → payment visible in transaction history in the app.
Modules¶
SD02 — KYC operations
| Module | Description |
|---|---|
| MOD-011 | Periodic review scheduler |
| MOD-012 | KYC audit trail |
| MOD-014 | List change propagation |
| MOD-015 | False positive management |
SD03 — AML monitoring
| Module | Description |
|---|---|
| MOD-016 | Rule-based typology engine |
| MOD-017 | ML anomaly scorer |
| MOD-018 | AML case management |
| MOD-019 | Regulatory report submission (STR / IFTI) |
| MOD-026 | IFTI/CMIR reporting trigger (from SD04 — co-deliver) |
SD01 — Core banking operations
| Module | Description |
|---|---|
| MOD-005 | Daily accrual calculator |
| MOD-006 | Rate change propagation |
| MOD-008 | Dormancy and escheatment |
SD04 — Payments core
| Module | Description |
|---|---|
| MOD-020 | Pre-payment validation suite |
| MOD-021 | Payment limit and velocity controller |
| MOD-022 | Payment audit trail |
| MOD-023 | Transaction fraud scorer |
| MOD-024 | Device and session intelligence |
SD07 — Platform
| Module | Description |
|---|---|
| MOD-075 | Internal API gateway |
SD08 — App MVP
| Module | Description |
|---|---|
| MOD-049 | Consent capture |
| MOD-050 | Disclosure enforcement |
| MOD-069 | App shell |
| MOD-070 | Transaction history |
| MOD-071 | Payment initiation |
| MOD-072 | Customer profile |
| MOD-077 | Account dashboard |
Phase gate¶
- Customer initiates NZD payment via app → validates (balance, limits, sanctions, fraud) → posts to ledger → payment visible in transaction history
- AML typology rules evaluate the payment → no false alert on a clean test transaction
- A synthetic high-risk payment triggers an AML alert and routes to the case queue
- An IFTI-threshold payment triggers regulatory submission workflow
- Consent and disclosure gates enforced — payment blocked without prior consent record
Phase 3 — Capital and credit¶
Mission: Prudential regulatory reporting operational. Credit products launchable. Multi-currency and FX active.
Capability milestone: LCR/NSFR dashboard populated from live data; RBNZ BS-series return producible; a credit application can be submitted, assessed, and approved end-to-end.
Modules¶
SD04 — Payments extensions
| Module | Description |
|---|---|
| MOD-025 | FX rate lock and conversion |
| MOD-061 | Open Banking API gateway |
| MOD-081 | Payment reconciliation engine |
| MOD-082 | Nostro and FX treasury management |
SD05 — Credit
| Module | Description |
|---|---|
| MOD-027 | Affordability calculator |
| MOD-028 | Credit score and risk rating |
| MOD-029 | Pre-approval engine |
| MOD-030 | IFRS 9 stage allocation |
| MOD-031 | ECL calculation and GL posting |
| MOD-059 | Credit bureau submission |
| MOD-065 | Credit servicing and collections |
| MOD-066 | Collateral and security management |
SD06 — Risk and regulatory
| Module | Description |
|---|---|
| MOD-032 | LCR / NSFR calculator |
| MOD-033 | Capital adequacy model (CAR / RWA) |
| MOD-034 | Interest rate risk model |
| MOD-035 | Stress testing engine |
| MOD-036 | Prudential return builder |
| MOD-037 | RBNZ data submission pipeline |
| MOD-038 | AML analytics and typology tuning |
| MOD-039 | Customer risk scoring model |
| MOD-040 | Counterparty credit risk model |
SD07 — Platform
| Module | Description |
|---|---|
| MOD-085 | Market rates feed |
| MOD-086 | Regulatory report orchestration |
SD08 — Back office
| Module | Description |
|---|---|
| MOD-051 | Financial automation rules |
| MOD-052 | Role-scoped data access |
| MOD-053 | Case and complaint management |
| MOD-064 | Operations work queue |
| MOD-074 | Back-office customer 360 |
| MOD-078 | Card and account controls |
| MOD-083 | Agent assist |
Phase gate¶
- LCR value computable from live Snowflake data and matches manual calculation
- RBNZ BS11 return cell values traceable to source ledger entries
- Credit application submitted → affordability calculated → credit bureau checked → decision recorded
- FX payment: rate locked, conversion executed, two-leg posting balanced in both currencies
- Open Banking consent flow operable end-to-end
Phase 4 — Intelligence¶
Mission: Full customer product suite. External asset aggregation. Expense intelligence. Advanced analytics.
Capability milestone: Customer can see their complete financial picture (bank accounts + KiwiSaver + property assets) in one app view; expense intelligence categorisation active for sole traders.
Modules¶
SD07 — External assets and wealth
| Module | Description |
|---|---|
| MOD-100 | External asset connector (Akahu / AU super) |
| MOD-101 | Wealth intelligence engine |
SD06 — Expense intelligence
| Module | Description |
|---|---|
| MOD-087–096 | Expense intelligence platform (sole trader, rental property, freelancer views) |
SD07 — Platform operations
| Module | Description |
|---|---|
| MOD-097 | Usage metering and billing |
| MOD-098 | Data quality monitoring |
| MOD-099 | Tenant environment provisioning |
SD08 — App completion
| Module | Description |
|---|---|
| MOD-054 | Call recording and transcript |
| MOD-073 | Document vault |
| MOD-084 | Inbound CDR data retrieval |
SD04 — International payments
| Module | Description |
|---|---|
| MOD-067 | Trade finance |
Phase gate¶
- Customer's KiwiSaver balance visible in net worth dashboard, refreshed daily
- A sole trader's business account transactions categorised with GST treatment applied
- Rental property income/expense view available in app
- All capability milestones from Phases 1–3 remain green (no regression)
Sequencing within a phase¶
Within a phase, modules can be built in parallel wherever their dependency constraints allow. Use the dependencies field in each module YAML as the authoritative ordering constraint — a module cannot be started until all its non-optional dependencies have build_status = Built.
To find all modules currently unblocked (all dependencies met), run:
For each module with build_status = Not started:
If all dependencies have build_status IN (Built, Deployed):
→ Eligible for assignment
The orchestrator maintains this eligibility list and assigns from it. Multiple agents can work on independent modules simultaneously.
What is not in this sequence¶
- FR expansion for high-complexity modules — deferred to execution-plan time per module. The 4 FRs currently defined are the minimum; modules in SD05 (credit), SD06 (risk), and SD03 (AML) will require expansion before agent assignment.
- Module design documents — produced by the agent as part of each module build; not pre-written.
- Time estimates — deliberately absent. Agent velocity is not yet calibrated. The phase gate is the progress measure, not elapsed time.