Cross-module acceptance suite

ID	MOD-160
System	SD07
Repo	bank-platform
Build status	Deployed
Deployed	Yes
Last commit	bbdfbac46a1b5cf6dc25b4c7cd428a8daa669d03

---

Purpose

MOD-160 runs end-to-end acceptance scenarios that cross system domain boundaries, validating that independently-deployed modules work correctly together as a bank. It answers the question that per-module integration tests cannot: does the system as a whole do what it is supposed to do?

Per-module integration tests (in each module's tests/integration/) verify that a module behaves correctly given a correctly-configured environment. MOD-160 verifies that the modules compose correctly — that data and events flow across boundaries, that state transitions in one module are visible to modules that depend on them, and that the user-facing outcomes (account activated, payment processed, notification received) actually materialise.

Architecture

MOD-160 deploys a set of acceptance scenario Lambda functions, each implementing one end-to-end flow. An EventBridge schedule triggers a dispatcher Lambda nightly that invokes each scenario function in dependency order and aggregates pass/fail results.

EventBridge Scheduler (nightly, 02:00 NZST)
  └── dispatcher Lambda
        ├── invokes scenario-001-customer-onboarding
        ├── invokes scenario-002-account-activation
        ├── invokes scenario-003-inbound-payment
        ├── invokes scenario-004-outbound-payment
        ├── invokes scenario-005-daily-accrual
        └── ... (scenarios added as modules are deployed)
        │
        └── aggregates results
              ├── CloudWatch custom metric: E2EAcceptanceSuitePass (1/0)
              ├── CloudWatch dashboard: bank-acceptance-{stage}
              └── SNS alert on failure → on-call channel

Scenarios that depend on modules not yet deployed are automatically skipped (the dispatcher checks the module's SSM output path before invoking the scenario). This means MOD-160 can be deployed early and the suite grows as the platform is built out.

Acceptance scenarios

Scenarios are added to this module as the platform reaches the phases where the relevant modules are built. The initial set covers Phase 1–4 modules:

Scenario	Modules exercised	Description
S-001 Customer onboarding	MOD-009, MOD-010, MOD-013	Onboard a test customer using a PASS eIDV identity; assert kyc_status = Verified, CDD tier assigned, sanctions clear
S-002 Account activation	MOD-007, MOD-009	Open an everyday account for a verified customer; assert state transitions from Pending to Active
S-003 Inbound credit	MOD-001, MOD-003, MOD-063	Submit an inbound payment event; assert ledger entry created, balance updated, notification dispatched
S-004 Outbound payment	MOD-020, MOD-001, MOD-003, MOD-022	Submit a payment instruction; assert validation passes, ledger posts, balance decrements, audit record created
S-005 Payment blocked — sanctions	MOD-013, MOD-020	Submit payment for a SANCTIONED counterparty; assert MOD-020 rejects with sanctions failure code
S-006 Daily accrual	MOD-005, MOD-001, MOD-003	Trigger daily accrual Lambda; assert interest posting appears in ledger and balance reflects
S-007 Notification capture	MOD-063	Trigger a customer notification; query MOD-157 notification capture log; assert message delivered within 30 seconds
S-008 eIDV fail → account blocked	MOD-009, MOD-007	Attempt onboarding with a FAIL eIDV identity; assert account remains in Pending state, not activated

Reporting

Results are reported at three levels:

1. CloudWatch dashboard (bank-acceptance-{stage}): one row per scenario, pass/fail status, last run time, duration
2. Custom metric E2EAcceptanceSuitePass (namespace BankPlatform/Acceptance): 1 if all enabled scenarios passed, 0 if any failed
3. SNS alert: fires to bank-ops-{stage} topic on first failure of the night; suppresses repeat alerts for 6 hours

Failed scenario Lambda logs include the full assertion failure message and the relevant entity IDs (customer_id, account_id, payment_id) for immediate investigation.

Scope

MOD-160 is deployed to dev and uat stages. It is not deployed to prod — production monitoring is handled by the observability platform (MOD-076) and module-specific CloudWatch alarms, not synthetic acceptance tests.

---

Module dependencies

Depends on

Module	Title	Required?	Contract	Reason
MOD-157	External provider stub service	Required	—	Acceptance scenarios exercise modules that call external providers; stubs must be deployed so scenarios run deterministically.
MOD-158	Test seed data loader	Required	—	Acceptance scenarios require seed customers, accounts, and GL configuration to be loaded before any cross-module flow can be exercised.
MOD-159	Synthetic transaction engine	Optional	—	Some acceptance scenarios validate that the synthetic transaction engine has produced correct ledger entries; MOD-159 is optional but its absence limits scenario coverage.
MOD-001	Double-entry posting engine	Optional	—	Ledger posting acceptance scenarios require MOD-001 to be deployed; scenarios that only cover identity and KYC flows can run without it.
MOD-009	eIDV & document verification	Optional	—	Customer onboarding acceptance scenarios require MOD-009; payment-only scenarios can run without it.
MOD-020	Pre-payment validation suite	Optional	—	Payment flow acceptance scenarios require MOD-020; identity-only scenarios can run without it.

Required by

(No modules in this wiki currently declare a dependency on this module.)

---

Policies satisfied

(No policies assigned)

---

Capabilities satisfied

(No capabilities mapped)

---

Part of SD07 — Data Platform & Governance Infrastructure Compiled 2026-05-22 from source/entities/modules/MOD-160.yaml