Correspondent banking risk gate¶


ID	`MOD-154`
System	SD04
Repo	`bank-payments`
Build status	Not started
Deployed	No

Purpose¶

The correspondent banking risk gate manages the full lifecycle of correspondent banking relationships — due diligence, onboarding approval, ongoing monitoring, and payment-level enforcement. Every outbound payment routed through a correspondent bank is checked against the approved correspondent registry; routing through an unapproved, suspended, or sanctioned correspondent is structurally impossible. The module also detects payable-through account patterns and nested correspondent relationships that exceed the institution's risk appetite.

What it does¶

Correspondent bank registry¶

All approved correspondent relationships are maintained in payments.correspondent_banks: correspondent_id, institution_name, BIC/SWIFT code, jurisdiction, AML_risk_rating (low/medium/high/prohibited), onboarding_date, last_review_date, next_review_due, approval_officers (list), approval_status (active/suspended/terminated), settlement_limit (maximum unsettled nostro exposure in AUD/NZD), and due_diligence_document_ids. Only correspondents with approval_status = active are eligible for payment routing.

Due diligence and onboarding workflow¶

A new correspondent relationship is initiated as a case in MOD-151 (Risk Case Console) with a structured due diligence checklist: AML programme assessment, beneficial ownership, FATF jurisdiction risk tier, sanctions history, regulatory standing in home jurisdiction, payable-through account usage, and disclosed nested correspondent relationships. Dual approval is required — Head of Payments and Chief Compliance Officer — before approval_status is set to active. The completed due diligence record is linked to the registry entry and retained for regulatory examination.

Payment routing gate¶

Before a payment is routed through a correspondent, the routing layer checks: (1) BIC is in the approved registry with status = active; (2) the correspondent's AML risk rating does not exceed the configured maximum for this payment type and corridor; (3) routing this payment would not cause the nostro settlement exposure to exceed the configured limit (from MOD-082); (4) the correspondent is not in a FATF non-cooperative jurisdiction above the permitted risk tier. A payment failing any check is blocked, an alert is sent to payments operations, and the block is logged in MOD-048.

Payable-through account detection¶

Payments arriving for further routing where the originating customer cannot be identified from the payment message are flagged and held for compliance review. The module checks for indicators in SWIFT MT/MX fields that suggest the correspondent is acting as a pass-through for an undisclosed originator.

Nested correspondent monitoring¶

The module tracks each approved correspondent's disclosed downstream correspondents. A routing chain that would pass through a prohibited or high-risk correspondent (nested) is blocked regardless of the immediate correspondent's approval status.

Compliance reason¶

FATF Recommendation 13 and its interpretive note impose specific due diligence requirements for correspondent banking: respondent institution AML programme assessment, enhanced due diligence for higher-risk respondents, prohibition on shell bank relationships, and payable-through account controls. The NZ AML/CFT Act 2009 s.22C and AU AML/CTF Act 2006 s.96 incorporate these FATF obligations. With PRD-004 (cross-border wallet) in the Tier 1 product set, these obligations apply at launch.

Commercial reason¶

A single payment routed through an unapproved correspondent is a regulatory breach that can result in enforcement action, de-risking by correspondent banks, and significant reputational damage. The onboarding gate and payment-level check make that outcome structurally impossible without requiring any manual intervention in the normal payment flow.

Module dependencies¶

Depends on¶

Module	Title	Required?	Contract	Reason
MOD-015	False positive management	Required	`contract/events/`	Sanctions screening of correspondent institutions uses the same sanctions list engine as customer screening — the correspondent BIC is screened before every payment routing decision.
MOD-082	Nostro & FX treasury management	Required	—	Nostro account balances for each correspondent are maintained in the nostro management module and are the settlement exposure input for the routing gate.
MOD-024	Device & session intelligence	Required	—	Domestic and cross-border payment initiation feeds into this module for correspondent routing decisions.
MOD-048	System decision log	Required	—	All correspondent registry decisions, onboarding approvals, payment blocks, and routing events are logged as immutable system decision entries.
MOD-103	Neon database platform bootstrap	Required	—	Neon database and schema provisioned by MOD-103 must exist before this module can read or write Postgres.
MOD-104	AWS shared infrastructure bootstrap	Required	—	AWS shared infrastructure provisioned by MOD-104 is required before this module can be deployed.

Required by¶

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

Policies satisfied¶

Policy	Title	Mode	How
AML-009	Correspondent Banking & Payments Policy	`GATE`	No payment may be routed through a correspondent bank that has not completed due diligence and received an active approval in the correspondent registry — enforced at the payment routing layer.
AML-007	Sanctions Screening Policy	`GATE`	Every correspondent institution and named intermediary in a payment chain is screened against sanctions lists before routing — a sanctions hit blocks the payment regardless of prior approval.
PAY-002	Settlement Risk Policy	`GATE`	Outbound payments are blocked when routing would cause the unsettled nostro exposure to a correspondent to exceed the configured settlement limit.
AML-008	Cross-Border Transfer Reporting Policy	`LOG`	All correspondent-routed cross-border payments are flagged for IFTI/CMIR evaluation in the cross-border reporting pipeline.

Capabilities satisfied¶

(No capabilities mapped)

Part of SD04 — Payments Processing Platform Compiled 2026-05-22 from source/entities/modules/MOD-154.yaml