Payment hold & friction engine¶
| ID | MOD-145 |
| System | SD04 |
| Repo | bank-payments |
| Build status | Not started |
| Deployed | No |
Purpose¶
Provide the ability to delay, hold, and subject to friction any outbound payment that exceeds a configurable risk threshold, satisfying the AU Scam-Safe Accord's obligation for participating banks to be capable of holding suspicious payments before they reach settlement. This is distinct from blocking a payment outright: the payment enters a held state, the customer is notified, and a defined resolution window applies before the payment is either released or cancelled.
What it does¶
Risk scoring integration. The payment rules engine (MOD-020) evaluates each outbound payment against a hold risk score before the payment is submitted to the settlement layer. Configurable signals that contribute to the score include: first payment to this payee, payment amount above a configurable threshold, payee added within the last N hours, a CoP no_match result from the confirmation of payee module (MOD-144), transaction velocity anomaly for the sending account, and destination account flagged by AML screening. The combined signal score is compared to a configurable hold threshold to determine whether and at what friction level the payment is held.
Three friction levels. The hold engine supports three levels of friction applied progressively based on risk score:
advisory— a warning is shown to the customer at the point of payment initiation. The customer may proceed freely; no queue delay is applied. Used for moderate-risk indicators where the institution wants to prompt reconsideration without creating friction.soft_hold— the payment is queued and not submitted to settlement. The customer must actively reconfirm within a configurable hold window (default 24 hours) for the payment to proceed. If no action is taken before the window expires, the payment is auto-cancelled and the customer is notified. The customer may also cancel proactively at any point during the hold window.hard_hold— the payment is queued and cannot be released by the customer. Back-office staff with thefraud_analystrole must review the payment and either release it to settlement or block it permanently. There is no expiry for hard_hold payments pending staff action; the institution's operational SLA governs review turnaround.
Payment holds table. The payments.payment_holds table records each hold event with the following columns: hold_id, payment_id, hold_level (advisory / soft_hold / hard_hold), hold_reason (structured reason codes corresponding to the signals that triggered the hold), risk_score, hold_at, hold_window_expires_at, resolved_at, resolution (customer_confirmed / customer_cancelled / staff_released / staff_blocked / expired_cancelled), and resolved_by.
Customer journey for soft_hold. When a payment is placed in soft_hold, the customer receives a push notification and sees an in-app banner linking to the held payment. The in-app view surfaces the payee details, the reason codes for the hold (in plain language), and two actions: reconfirm or cancel. If the customer reconfirms, the hold is lifted and the payment is submitted to settlement in the next processing cycle. If the customer cancels, the payment record is closed and funds are returned to the available balance immediately. If neither action is taken before hold_window_expires_at, the payment is auto-cancelled and a cancellation notification is sent.
Staff review queue. Hard_hold payments appear in the back-office fraud review queue accessible to users with the fraud_analyst role. Each queue item displays the full payment context (payee, amount, channel, payment history to this payee), the CoP result if available, the risk score and contributing signals, and the customer's recent contact history. Staff may release the payment to settlement or block it permanently. All staff decisions are logged with the resolved_by identity (staff user ID), timestamp, and optional notes. These records are immutable once written.
Hold window configuration. Hold window durations are configurable per deploying institution. The platform default is 24 hours for soft_hold and no expiry for hard_hold pending staff action. The RBNZ and Scam-Safe Accord do not mandate a specific window duration; the deploying institution sets the value appropriate to their risk management framework and operational capacity.
Bypass conditions. The hold engine is bypassed for intra-bank transfers processed through MOD-141, internal system-initiated payments, and BPAY payments to billers already recorded on the institution's trusted biller list. These payment types carry a different risk profile and are not subject to hold evaluation.
Operational metrics. Hold rate, release rate, customer cancellation rate, staff cancellation rate, and average hold duration are surfaced in the operational dashboard. These metrics allow the institution to monitor the effectiveness and calibration of the hold threshold over time.
Compliance reason¶
The AU Scam-Safe Accord requires signatory banks to hold suspicious outbound payments rather than processing them immediately at risk. Without a hold capability, the platform cannot satisfy this Accord commitment, and the deploying institution has no technical defence against rapid authorised push payment (APP) scams. By the time a customer reports an APP scam, the payment has already settled and the recipient has withdrawn the funds — recovery is negligible. The hold window is the point at which the institution can interrupt the fraud before it becomes irrecoverable. The hard_hold level provides an additional backstop for the highest-risk cases, where staff review before release is the appropriate control.
Commercial reason¶
Reduced APP fraud losses directly reduce reimbursement liability under the Scam-Safe Accord's consumer reimbursement framework, which places shared liability on the receiving and sending banks. Each prevented fraud event avoids both the direct reimbursement cost and the operational cost of fraud investigation, customer remediation, and dispute handling. The configurable friction system lets each deploying institution tune the hold threshold and friction levels to their risk appetite and customer experience tolerance without requiring a code change — the institution can tighten or loosen thresholds in configuration as their fraud data evolves.
Module dependencies¶
Depends on¶
| Module | Title | Required? | Contract | Reason |
|---|---|---|---|---|
| MOD-020 | Pre-payment validation suite | Required | — | The payment rules engine evaluates risk signals and sets the hold flag before the payment reaches the settlement layer. |
| MOD-024 | Device & session intelligence | Required | — | Outbound domestic payments pass through the hold engine as part of the submission pipeline. |
| MOD-025 | FX rate lock & conversion | Required | — | Scheduled and future-dated payments are evaluated at initiation and again at execution time. |
| MOD-063 | Notification orchestration | Required | — | Customer is notified of the hold and prompted to reconfirm or cancel via the notification engine. |
| MOD-018 | Alert case management system | Required | — | Held payments that are not resolved by the customer within the hold window are escalated to the AML alert case management system. |
| MOD-048 | System decision log | Required | — | Every hold event, customer interaction, and release or cancellation decision is recorded as an immutable decision log entry. |
| 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 | AUTO |
High-risk payments are automatically held pending customer reconfirmation or staff review — hold prevents immediate loss in the event of a scam or fraud attempt. |
| AML-007 | Sanctions Screening Policy | ALERT |
Payments held for risk review generate an alert in the AML case management system for compliance assessment. |
Capabilities satisfied¶
(No capabilities mapped)
Part of SD04 — Payments Processing Platform
Compiled 2026-05-22 from source/entities/modules/MOD-145.yaml