Scam intelligence reporting & reimbursement¶


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

Purpose¶

Satisfy the two Scam-Safe Accord obligations not covered by fraud detection or payment hold modules: (1) sharing scam intelligence with the ABA Scam Intelligence Hub, and (2) processing consumer reimbursement claims under the Accord's no-fault reimbursement framework. Together these complete the platform's full Scam-Safe Accord coverage alongside MOD-144 (Confirmation of Payee) and MOD-145 (payment hold).

What it does¶

Scam intelligence reporting¶

A weekly intelligence export is generated from confirmed scam events in the AML case management system (MOD-018) and payment fraud records. The export identifies scam typologies observed (investment scam, romance scam, impersonation, and others), mule account BSBs and account numbers where scam proceeds were received, payment corridors, and average loss amounts.

The export is formatted to the ABA Scam Intelligence Hub API specification and submitted automatically via secure API. Submission confirmation and hub reference numbers are stored against each export record.

The payments.scam_intelligence_submissions table records: submission_id, period_start, period_end, typologies_reported, mule_accounts_reported, total_cases, hub_reference, submitted_at, and status (submitted / acknowledged / failed).

The compliance team can suppress individual mule account records from a submission if legal proceedings are ongoing — a manual override flag prevents that record from being included in future exports until released.

This function is AU only. The ABA Scam Intelligence Hub is an Australian Banking Association initiative. The module is inactive for NZ-only deployments.

Consumer reimbursement¶

When a customer reports a scam payment, a reimbursement case is opened in MOD-053 as a scam_reimbursement case type. The case carries statutory SLA timers consistent with IDR obligations.

The reimbursement assessment workflow evaluates three factors: whether the bank's controls failed (CoP result from MOD-144, hold engine decision from MOD-145, fraud alerts raised), customer vulnerability indicators, and whether the customer took reasonable care. The Accord sets a no-fault default for cases where the bank's controls failed — in those cases, full reimbursement is the starting position unless exceptional circumstances apply.

The payments.scam_reimbursements table records: reimbursement_id, case_id, payment_id, claimed_amount, assessment_outcome (approved_full / approved_partial / declined), bank_fault_determination, customer_care_determination, approved_amount, reimbursement_gl_entry_id, decided_at, and decided_by.

Approved reimbursements are posted as a credit to the customer's account via a MOD-001 ledger entry. The offsetting debit posts to the institution's fraud loss GL account, which is configured in MOD-140. Declined reimbursements trigger the standard IDR communication process in MOD-053, with the customer notified of their right to escalate to AFCA.

Reimbursement metrics — case volumes, approval rates, average amounts, and time-to-decision — are reported monthly to the board risk committee and annually to the ABA as part of the Accord compliance report.

Compliance reason¶

The Scam-Safe Accord has two commitments addressed by this module. Intelligence sharing (Article 4 of the Accord) requires banks to contribute scam typology and mule account data to the shared intelligence platform — this is a collective defence obligation that cannot be met without a systematic export process. The consumer reimbursement framework (Article 5) requires participating institutions to assess and pay no-fault reimbursements in defined circumstances. Without a governed workflow and a ledger-connected reimbursement entry, cases are handled inconsistently and the institution cannot demonstrate Accord compliance. The IDR SLA timers ensure the reimbursement process also meets the existing dispute resolution obligations under RG 271.

Commercial reason¶

Scam intelligence sharing benefits the institution directly — intelligence contributed by other banks about mule accounts and typologies improves the platform's own fraud detection inputs. The reimbursement workflow, while representing a cost, replaces an ad hoc process that carries higher legal and reputational risk when handled inconsistently. A systematic assessment process also allows the institution to quantify and manage its reimbursement exposure over time, informing fraud loss provisioning and risk appetite decisions.

Module dependencies¶

Depends on¶

Module	Title	Required?	Contract	Reason
MOD-053	Case & complaint management module	Required	—	Scam reimbursement cases are created as a specialised case type within the case management system — SLA tracking and agent workflow use the same case management infrastructure.
MOD-001	Double-entry posting engine	Required	—	Approved reimbursement amounts are posted as compensatory credit entries via the core ledger — the reimbursement is a real financial transaction not a manual journal.
MOD-037	AUSTRAC / RBNZ AML reporting pipeline	Required	—	AML reporting pipeline provides scam typology data and mule account identifiers for intelligence hub submissions.
MOD-018	Alert case management system	Required	—	Scam cases escalated from alert case management are the primary source of confirmed scam events for intelligence reporting.
MOD-048	System decision log	Required	—	All intelligence submissions, reimbursement decisions, and ledger entries are recorded as immutable decision log 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 (EventBridge buses, S3, KMS, Kinesis, Cognito) 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
PAY-005	Payment Fraud Prevention Policy	`LOG`	Scam typology reports and mule account intelligence are submitted to the ABA Scam Intelligence Hub on a defined schedule — intelligence sharing obligation met automatically.
CON-002	Complaints & Internal Dispute Resolution Policy	`AUTO`	Scam reimbursement cases are tracked through the IDR workflow with statutory SLA timers — reimbursement decisions are documented and communicated within required timeframes.

Capabilities satisfied¶

(No capabilities mapped)

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