Business goals¶
Business goals define what the bank aims to achieve. Each goal has non-functional requirements and maps to capabilities delivered by system modules. All goals are traceable to modules in the systems register.
Customer & growth goals¶
BG-001 — Frictionless digital onboarding for NZ and AU customers¶
A customer can open a fully functional account, verify identity, and make a payment — entirely on mobile, in under 5 minutes, without visiting a branch or calling anyone.
| Code | Non-functional requirement |
|---|---|
| NFR-001 | Onboarding completion rate ≥ 80% of started applications for standard-risk customers. |
| NFR-002 | End-to-end onboarding time ≤ 5 minutes for 90th percentile of standard customers. |
| Capability | ID |
|---|---|
| Digital KYC — document + selfie verification | CAP-045 |
| Real-time account opening | CAP-046 |
| NZ/AU resident onboarding | CAP-047 |
| CDD automatic tier assignment | CAP-062 |
What this looks like in practice¶
A customer downloads the app, uploads their NZ driver's licence, completes a biometric liveness check, and is active with a NZD everyday account within 3 minutes and 47 seconds. Their identity is verified against the DIA document verification service in real time. CDD tier is assigned automatically. Sanctions screen completes in the background. They receive their virtual card instantly and can make a contactless payment before their physical card arrives.
Why this matters to stakeholders: Legacy banks take 3–5 business days to open an account. A digital bank that opens one in under 5 minutes is not a marginal improvement — it is a category change. Every minute of onboarding friction converts to churn before the relationship starts. At 10,000 customers onboarded, a 5-minute p90 target means thousands of people who would have abandoned a slower process are now active customers.
What the system does automatically: MOD-009 (eIDV) and MOD-010 (CDD tier assignment) run without human intervention. The account is active or declined without any agent involvement. The customer never speaks to a human unless the eIDV confidence score falls below the threshold requiring EDD.
BG-002 — Seamless NZD ↔ AUD cross-border experience¶
Customers with both NZ and AU accounts see a unified financial picture and can transfer between currencies instantly with full rate transparency.
| Code | Non-functional requirement |
|---|---|
| NFR-003 | Cross-border wallet transfer settlement ≤ 2 minutes for 99th percentile. |
| Capability | ID |
|---|---|
| NZ bank account (NZD) | CAP-001 |
| AU bank account (AUD) | CAP-002 |
| Multi-currency wallet | CAP-003 |
| Foreign exchange — live rates, rate lock | CAP-006 |
| Transparent FX markup display | CAP-043 |
What this looks like in practice¶
A customer living in Auckland with family in Melbourne opens both a NZ and AU account from the same app in the same session. They see both balances on their home screen expressed in NZD equivalent. When they want to send money to their AU account, they tap the transfer button, see the live exchange rate and all-in cost, and confirm within the 45-second rate lock window. The money appears in their AU account within seconds.
The FX rate screen shows: "You're sending NZD 500. Rate: 1 NZD = 0.9231 AUD (mid-market rate 0.9291 · our spread 0.65%). You receive AUD 461.55." Nothing is hidden.
Why this matters to stakeholders: The NZD↔AUD pair is one of the most frequently transacted cross-border pairs in the world. There are over 600,000 NZ citizens living in Australia and significant movement in both directions. Every one of these people currently pays 1.5–3% in hidden FX margins to their bank, wait 1–2 business days for settlement, and need separate apps or accounts for each country. This bank eliminates all three pain points simultaneously.
What the system does automatically: The atomic dual-ledger post (four journal entries in a single Postgres transaction), IFTI/CMIR reporting trigger, FX nostro balancing — all automated. No human touches this workflow.
BG-003 — Intelligent financial assistant — proactive, personalised, automated¶
The app acts as a financial companion — detecting idle cash, surfacing savings opportunities, offering pre-approved credit, flagging spend anomalies, and automating repetitive tasks.
| Code | Non-functional requirement |
|---|---|
| NFR-004 | Insight cards refreshed within 60 seconds of a qualifying transaction or balance event. |
| Capability | ID |
|---|---|
| Proactive financial insight engine | CAP-063 |
| Customer automation rules | CAP-064 |
| Pre-approval engine | CAP-065 |
| Unusual transaction alert | CAP-022 |
What this looks like in practice¶
A customer opens the app on a Monday morning and sees their home screen personalised to their situation:
- "NZD 1,200 is earning nothing" — Idle cash detected in the everyday account for 14 days above their typical spending buffer. "Move to savings and earn NZD 4.80/month at 4.8% p.a." One-tap action.
- "You're pre-approved for a personal loan" — Based on 8 months of account history, stable salary, and low debt-to-income ratio. "Up to NZD 15,000 at 9.9% p.a. No impact on your credit score to check terms." One-tap.
- "Power bill up 43% this month" — Contact Energy charged NZD 284 vs 6-month average of NZD 198. "This is the 2nd increase in a row. Want to see your utility spend history?" One tap to a chart.
- "Good time to top up your AU account" — NZD/AUD is at a 3-month high. "Transfer now and get ~1.2% more AUD than last month." One-tap to the FX transfer screen.
Why this matters to stakeholders: Legacy banks show a balance and a transaction list. This bank shows insights derived from the customer's actual financial behaviour, with one-tap actions that make it trivially easy to act. The insight cards are not marketing — they are contextual financial guidance based on real data.
What the system does automatically: The Snowflake intelligence layer (MOD-039 through MOD-041) computes idle cash detection, pre-approval eligibility, spend anomalies, and FX rate signals nightly. Results written back to Postgres. The home screen reads pre-computed signals — no live Snowflake query on page load.
BG-004 — Maximum self-service — zero call required for routine tasks¶
Every routine banking task is completable in the app without contacting support.
| Code | Non-functional requirement |
|---|---|
| NFR-005 | ≥ 85% of customer service requests resolved without human agent involvement. |
| Capability | ID |
|---|---|
| Customer dispute & chargeback portal | CAP-039 |
| Spending limits & card controls | CAP-015 |
| Instant card freeze / unfreeze | CAP-016 |
| Self-service KYC refresh | CAP-066 |
What this looks like in practice¶
A customer loses their card at 11pm on a Saturday. They open the app, freeze the card in 8 seconds, order a replacement, and enable their digital wallet for Apple Pay immediately. Total time: 90 seconds. No call centre, no hold music, no waiting until Monday.
A different customer disputes a transaction they don't recognise. They tap the transaction, tap "Dispute", describe the issue in two sentences, and submit. The dispute is logged and routed automatically. They receive a provisional credit within 24 hours while the investigation runs. They never speak to a human unless the dispute needs human adjudication.
Why this matters to stakeholders: Every phone call to a support agent costs the bank approximately NZD 8–15 in handling cost. A self-service rate of 85% versus 60% (typical for a legacy bank) saves hundreds of thousands of dollars per year in support cost — and simultaneously produces higher customer satisfaction scores because customers prefer resolving things instantly in an app at midnight over waiting on hold.
The 15% that does reach an agent: These are genuinely complex cases — fraud investigations, hardship assessments, complaints, KYC edge cases. The back office platform (SD08) gives the agent a complete Customer 360 view and the Snowflake intelligence context when the case lands. The agent doesn't start from scratch.
Financial & commercial goals¶
BG-005 — Build a profitable, stable deposit base from day one¶
Gather low-cost retail deposits through competitive savings and term deposit rates.
| Code | Non-functional requirement |
|---|---|
| NFR-006 | Interest accrual posted to all deposit accounts by 23:59 each business day. |
| Capability | ID |
|---|---|
| High-interest savings account | CAP-051 |
| Term deposits | CAP-052 |
| Idle cash detection | CAP-067 |
| Daily interest accrual display | CAP-076 |
What this looks like in practice¶
A customer with NZD 12,840 in savings sees their savings account is earning 4.8% p.a. When a term deposit campaign runs at 5.2% p.a. for 6 months, they receive a personalised push notification: "Lock in 5.2% on your savings for 6 months — that's NZD 667 in interest." They tap, review the terms, and open the term deposit in 45 seconds.
Why this matters to stakeholders: A term deposit customer is the most valuable customer on the liability side of the balance sheet. They lock in funding at a known cost for a defined period, which makes the bank's liquidity and interest rate risk management significantly simpler. Each term deposit opened reduces the LCR buffer the bank needs to hold.
What the system does automatically: The NBA (Next Best Action) engine in Snowflake identifies customers with high term deposit propensity based on balance, savings behaviour, and product holdings. The campaign execution layer routes the notification. The onboarding is self-serve — no branch, no agent, no paperwork.
BG-006 — Real-time credit decisioning — fast, responsible, automated¶
Credit decisions made in seconds using live data. Responsible lending obligations met automatically by the decisioning engine.
| Code | Non-functional requirement |
|---|---|
| NFR-007 | Credit decision returned in ≤ 10 seconds for standard-risk applications using pre-scored data. |
| Capability | ID |
|---|---|
| Automated credit decisioning engine | CAP-068 |
| Affordability calculator | CAP-069 |
| Pre-approval engine | CAP-065 |
What this looks like in practice¶
A customer applies for a NZD 10,000 personal loan at 9pm on a Sunday. The affordability calculator runs instantly against their 6-month transaction history: income NZD 5,400/month verified, committed expenses NZD 1,200, estimated living costs NZD 1,800, existing debt NZD 0. Net disposable income: NZD 2,400/month. Requested repayment: NZD 320/month. Decision: approved at 9.9% p.a. Time elapsed: 4.2 seconds.
The customer is shown the full affordability assessment. They accept, and the funds land in their account immediately.
Why this matters to stakeholders: Legacy banks take 24–48 hours to approve a personal loan because a human reviews the application. This bank approves in seconds because the affordability model runs on Snowflake with real transaction data. The responsible lending documentation is produced automatically — the audit trail is the model output. This gives the bank a significant customer acquisition advantage for time-sensitive borrowing needs.
What the system does automatically: MOD-027 (affordability calculator), MOD-028 (credit score), MOD-029 (pre-approval engine) — all automated. The credit decision is documented without human involvement. The CCCFA and NCCP obligations are met by the system architecture, not by a manual process.
BG-007 — Capital and liquidity managed in real time — no surprises¶
Capital ratios, LCR, and NSFR computed continuously from live ledger data. Breaches detected before they occur.
| Code | Non-functional requirement |
|---|---|
| NFR-008 | Capital and liquidity metrics available within 5 minutes of any material balance sheet event. |
| Capability | ID |
|---|---|
| Real-time capital ratio engine | CAP-070 |
| LCR/NSFR continuous calculation | CAP-071 |
| Regulatory threshold alerting | CAP-072 |
What this looks like in practice¶
The Chief Risk Officer opens the risk dashboard at 7:30am and sees: LCR 142% (above the 100% minimum), CET1 ratio 11.8% (above the 8% effective minimum), NZD/AUD FX exposure NZD 2.1M net long (within the treasury hedging threshold). All figures are current as of the most recent end-of-day calculation.
If the LCR drops below the 110% internal early warning threshold during the day, an automatic alert fires to Treasury and the CRO. They do not discover a liquidity problem in the next day's report — they see it when it happens.
Why this matters to stakeholders: RBNZ and APRA expect banks to manage capital and liquidity proactively. A bank that discovers a capital or liquidity issue in a regulatory report cycle is a bank that was reporting risk retrospectively, not managing it. Real-time dashboards powered by Snowflake give the Board and management a genuine picture of the bank's position.
What the system does automatically: MOD-032 (LCR/NSFR), MOD-033 (RWA/capital ratio), MOD-035 (IRRBB) — all running on Snowflake dynamic tables from live ledger data. No spreadsheets. No manual calculation. No T+1 lag.
Operational goals¶
BG-008 — One front end — customer and operations from the same codebase¶
A single application with mode-aware rendering serves both customers and back office staff.
| Code | Non-functional requirement |
|---|---|
| NFR-009 | Zero divergence in UI component library between customer and back office modes. |
| Capability | ID |
|---|---|
| Dual-mode rendering engine | CAP-073 |
| Role-scoped API gateway | CAP-074 |
| Shared UI component library | CAP-075 |
What this looks like in practice¶
A compliance officer investigating an AML alert logs into the same app they use every day. Their sidebar navigation shows: Customers, Operations, Compliance (active), Risk, Admin. They open the alert, see the full customer context — KYC status, risk score, 90-day transaction history, previous alerts — and make a dismissal or escalation decision. The decision is logged in the audit trail.
The agent who later takes a call from the same customer sees the same customer record, but their sidebar shows: Customers, Operations, Cases — not the Compliance menu. The compliance case is not visible to them. One app, two different role-scoped experiences.
Why this matters to stakeholders: Back office tools at legacy banks are typically fragmented — one system for account management, a separate system for compliance, another for collections. Agents switch between 3–4 screens per customer interaction, copying reference numbers between systems. The single-GUI approach eliminates this. Every function is in one codebase, and the role system controls what each person sees.
BG-009 — Automate everything that can be automated — minimise ops headcount¶
Regulatory reporting, AML submissions, interest accrual, KYC reviews, risk scoring, and customer communications are all automated.
| Code | Non-functional requirement |
|---|---|
| NFR-010 | ≥ 90% of regulatory submissions produced without manual intervention. |
| Capability | ID |
|---|---|
| Automated regulatory reporting pipeline | CAP-025 |
| Exception-only case routing | CAP-026 |
| Automated AML submission pipeline | CAP-027 |
What this looks like in practice¶
At month-end, the APRA ARS reporting pack is generated by the Snowflake pipeline (MOD-036). Every figure is traceable to source ledger entries. The pack is reviewed by the CFO and Chief Risk Officer, who have a dashboard showing any validation anomalies. They approve and the submission is made. Total human time: 45 minutes of review. Total time for data preparation: 0 minutes.
The same pipeline generates the RBNZ BS-series returns, the AUSTRAC annual compliance data, and the IFTI/CMIR submissions — all automated, all sourced from the same data pipeline, all with cell-level data lineage.
Why this matters to stakeholders: Regulatory reporting at a legacy bank employs multiple full-time staff doing manual data extraction, reconciliation, and submission formatting. At this bank, the regulatory reporting function is primarily a review and approval function — the data assembly is automated. This is both a cost saving and a quality improvement: automated pipelines make fewer transcription errors than manual assembly.
What the system does automatically: The entire Snowflake regulatory reporting suite (SD06) produces submission-ready returns without manual data work. Policy REP-001 is satisfied by AUTO mode — the system, not the staff.
BG-010 — Governance and compliance built in — not bolted on¶
Every policy obligation satisfied by a system module. The audit trail is the system log.
| Code | Non-functional requirement |
|---|---|
| NFR-011 | Zero policies in the register with no automated system satisfaction. |
| Capability | ID |
|---|---|
| Policy-as-code satisfaction framework | CAP-028 |
| Immutable audit log | CAP-029 |
| Regulator evidence portal | CAP-030 |
What this looks like in practice¶
An RBNZ examiner asks: "Show me your evidence that every account that has been opened has had a compliant CDD check, and show me the decision trail for any account where EDD was triggered."
The response: a Snowflake query returning every account opened in the requested period, the eIDV confidence score, the CDD tier assigned, the date of the check, the operator ID if a human reviewed it, and the model version that produced the assessment. For EDD accounts: the date EDD was triggered, the trigger reason, the documents collected, and the date of completion. Export as CSV in 30 seconds.
Why this matters to stakeholders: Regulatory examinations at legacy banks require weeks of manual evidence compilation. At this bank, the audit trail is the system log. Every decision is a database record. Evidence can be produced for any period, any customer, any process in minutes.
The Systems & Modules Register documents exactly which module satisfies each policy and by what mechanism. The bank can demonstrate to any regulator, auditor, or board committee that every compliance obligation has a documented, automated control — not a process that relies on humans remembering to do it.
Platform & SaaS goals¶
BG-011 — License the platform to smaller financial institutions as modular SaaS¶
Building societies, mutual banks, credit unions, and regional banks in NZ and AU are offered the platform as single-tenant SaaS. Each institution deploys under its own brand and regulatory licence. Modules are selected per institution; no institution shares infrastructure with another.
| Code | Non-functional requirement |
|---|---|
| NFR-012 | Tenant data segregation enforced at the database, API, and identity layers — zero cross-tenant data leakage in any failure mode. |
| NFR-013 | New tenant environment provisioning completed within 5 business days from signed contract to live sandbox. |
| Capability | ID |
|---|---|
| Tenant environment provisioning | CAP-031 |
| Per-tenant module configuration | CAP-032 |
| Tenant data isolation | CAP-033 |
What this looks like in practice¶
A NZ building society signs a contract for the Standard tier (core ledger + payments + KYC). Within 5 business days they have a sandbox environment under their own subdomain, pre-loaded with their branding configuration, running with their own Neon database instance and Cognito user pool. Their data never touches another institution's environment. Their staff access the back office under their own identity provider. Their customers use an app that shows their brand, not ours.
The platform team deploys module updates centrally. Each tenant environment receives updates through the same CI/CD pipeline (ADR-022), with tenant-specific feature flags (ADR-033) controlling rollout timing.
Why this matters to stakeholders: Every module built to satisfy the direct bank's regulatory obligations also satisfies the same obligations for a NZ or AU institution operating under the same regulatory framework. The compliance investment is made once and amortised across multiple tenants. The marginal cost of adding a new NZ institution to the platform is infrastructure and onboarding — not compliance re-engineering.
BG-012 — NZ pilot in Year 1, AU in Year 2, international from Year 3¶
The SaaS platform is piloted with one or two NZ institutions in Year 1, expanded to AU in Year 2, and offered to international markets from Year 3.
| Code | Non-functional requirement |
|---|---|
| NFR-014 | A new jurisdiction (regulatory reporting profile, product configuration, identity verification provider) shall be onboardable without changes to platform core modules. |
| Capability | ID |
|---|---|
| Jurisdiction configuration layer | CAP-034 |
| Per-jurisdiction regulatory report profiles | CAP-035 |
What this looks like in practice¶
The NZ pilot operates under RBNZ/FMA supervision. The institution's regulatory reporting (BS-series returns, AUSTRAC/FMA AML submissions) is produced by the same Snowflake pipeline used for the direct bank, with tenant-specific report profiles. When the platform expands to AU, APRA ARS reporting and AUSTRAC AML/CTF requirements are already implemented from the direct bank — the AU institution gets those profiles configured, not rebuilt.
When a Pacific island institution (e.g. operating under the Reserve Bank of Fiji or RBNZ's Pacific oversight framework) joins in Year 3, their jurisdiction profile is added as configuration — new regulatory report templates, updated product rules — without touching the core ledger, KYC, or payment modules.
Why this matters to stakeholders: The largest cost in banking technology is not development — it is compliance. A platform that already operates under RBNZ and APRA supervision has a compliance profile that no new entrant can replicate cheaply. Every new market that shares a similar regulatory framework is an incremental configuration exercise, not a greenfield build.
Pilot sequencing:
| Phase | Timeline | Target |
|---|---|---|
| Phase 1 | Year 1 | 1–2 NZ institutions (building societies or mutual banks) |
| Phase 2 | Year 2 | AU institutions (COBA members) |
| Phase 3 | Year 3+ | Pacific, Southeast Asia, UK building societies |
See market-opportunity.md for market data and indicative pricing.
Proposed goals¶
The following goals are proposed and under consideration. They are recorded here for visibility and planning. They do not yet have approved requirements or committed build scope.
BG-015 — Become the financial operating system for sole traders, SMEs, and property investors¶
Replace hours of manual accounting work with continuous, intelligent, real-time financial structuring embedded in the bank. Sole traders, small businesses, and residential property investors should be able to file GST, track rental P&L, separate business from personal spend, and manage provisional tax — without opening a spreadsheet or a separate accounting application.
| Capability | ID |
|---|---|
| Transaction intelligence enrichment | CAP-134 |
| Personal/business expense classification | CAP-135 |
| Sole trader & SME tax automation (GST, provisional tax) | CAP-136 |
| Rental property income tracking & ring-fencing | CAP-137 |
| Multi-entity party model — single user across all entities | CAP-138 |
| Receipt capture, OCR & expense reconciliation | CAP-139 |
What this looks like in practice¶
- A sole trader opens the app and sees "You have 4 transactions to review — 30 seconds." Swipes through, confirms three auto-suggestions, adjusts one. Running GST balance updates automatically.
- A property investor sets up "12 Smith St" once. From then on, rent inflows are attributed automatically, rates and insurance are recognised as property expenses, and a ring-fenced loss balance is maintained in real time without any spreadsheet.
- A director with two Ltd companies and a charity treasurer role opens one app with one login and switches between contexts — their own accounts, the company accounts, and the charity accounts — without logging out.
- At the end of the GST quarter: "Your return is ready. $412 refund. Review and file?" One tap.
- A Xero user connects once. From then on, Xero receives pre-classified, GST-coded transactions. The chart-of-accounts mapping is already done. No Xero rule setup required.
Benchmark: Hnry (NZ/AU) owns the sole trader tax automation workflow today — but is not a bank. The first bank to natively replicate and extend this capability owns the segment.
Status: Proposed — design complete (see Expense Intelligence platform and Customer, party and user schema). Module design (MOD-087 to MOD-096) to follow.
BG-016 — Give every customer a complete, real-time picture of their financial position¶
A customer can see their true net worth — bank deposits, loans, property equity, KiwiSaver, and Australian superannuation — in a single view, updated daily, without logging into multiple apps. KiwiSaver health indicators (government match gap, PIR mismatch risk) surface actionable insights from data the customer has already consented to share.
| Capability | ID |
|---|---|
| External financial asset aggregation (Akahu / direct AU super) | CAP-141 |
| Net worth dashboard — tiered by liquidity | CAP-142 |
| KiwiSaver & super optimisation insights | CAP-143 |
What this looks like in practice¶
- A customer opens the app and sees their total net worth: $87,400 — broken into "available now: $12,200 / term deposit: $15,000 (matures 12 Aug) / KiwiSaver: $54,200 / home equity: ~$6,000." One number, four layers.
- In June: "You're $340 short of the full government KiwiSaver match. A $95 top-up before 30 June unlocks $170 from the government." No advice — just math.
- A customer who changed jobs and earns $55,000 sees: "Your KiwiSaver tax rate may be set to 17.5% — your income suggests 28% applies. Check with [provider]." No recommendation to switch funds — a prompt to check a fact.
Note: KiwiSaver and superannuation data is unit-priced daily and retrieved under explicit customer consent via Akahu (NZ) or direct provider APIs (AU). This is not real-time. External asset balances are labelled "as at [date]" throughout the UX.
FMA boundary: CAP-143 insights are factual computations on the customer's own data. No fund recommendations, no contribution directives, no provider comparisons. Legal review of all display copy required before release. See ADR-041.
Status: Proposed — design complete (see Wealth aggregation). MOD-100 and MOD-101 defined, not yet in build queue.
BG-013 — Open Banking platform participation and API monetisation¶
Participate actively in AU CDR and NZ Open Banking frameworks as a Data Holder, and operate a commercial API access programme for fintechs and enterprise customers.
| Capability | ID |
|---|---|
| CDR Data Holder compliance & consent management | CAP-060 |
| Commercial API programme & developer portal | CAP-061 |
Status: Proposed — pending demand validation for Phase 3 (commercial API programme). Phase 1 (CDR compliance) is non-discretionary. See ADR-037.
BG-014 — Automated bank migration via Open Banking¶
Use inbound Open Banking data retrieval to pre-fill account opening and automate transaction history migration when a customer nominates their existing bank. Target: customer completes full migration in under 10 minutes with no manual document upload.
| Capability | ID |
|---|---|
| Automated direct debit migration | CAP-048 |
| CDR Data Holder compliance & consent management | CAP-060 |
Status: Proposed — feasibility pending market readiness survey (CDR Data Holder coverage across NZ banks). No module created until feasibility assessment is complete. See ADR-037.