> ## Documentation Index > Fetch the complete documentation index at: https://banking.nextedge.consulting/llms.txt > Use this file to discover all available pages before exploring further. # B26 Risk fraud AML and compliance > Apply institution-owned risk controls and handle reviewable cases without silently making autonomous decisions. **Review draft • 14 October 2026 • New Banking project • Implementation not started.** ## Definition and responsibility Risk, fraud and anti-money-laundering work reviews signals and cases under institution-owned policy. A signal is evidence to assess, not an autonomous licence to deny a customer, file a regulatory report or change an account restriction. | Attribute | Module definition | | - | - | | Entry condition | Onboarding, transaction monitoring or a reported event creates a risk signal. | | Owned records | Signal, screening result, investigation case and authorised disposition. | | Functional output | A recorded case decision and any separately confirmed protective action or filing. | | Configuration | See **Required configuration** below. Parameters require institution-approved values and effective versions. | | Application entry points | Restricted Banking Operations risk/compliance workspaces. Ordinary customer/staff screens do not expose investigation evidence. Access is governed by the approved institution permission matrix. | ### How it differs from related modules | Related module | Boundary and handoff | | - | - | | [B04 Customer onboarding and KYC](/banking/modules/b04) | B04 verifies customer identity; B26 investigates risk/screening signals during and after onboarding. | | [B32 Security audit deployment and resilience](/banking/modules/b32) | B26 concerns financial/customer risk cases; B32 concerns platform security, audit and resilience. | Read the [module comparison map](/banking/module-boundaries) for the whole platform and the [glossary](/banking/glossary) for shared terms. Planned operating duties: Risk analyst; AML investigator; compliance officer; authorised decision maker. Access to these duties requires the approved institution permission matrix. The bank or authorised regulated entity owns product policy and financial outcomes. Platform operators receive no automatic customer-data, fund-movement or issuer authority. ## Worked Indian example Use the four stages below to distinguish the initial facts, the action to test, confirmed completion and the alternate result. This example exercises this module’s responsibility; related modules still own the handoffs listed above. **Fictional requirements illustration, not seeded data or approved banking policy.** Reference: RISK-001 / onboarding name match. | Stage | Example | | - | - | | Starting situation | Screening returns a potential match for CUSTOMER-001. | | Operator/customer actions | Create a restricted investigation case, gather permitted evidence and route to the accountable reviewer. | | Expected normal outcome | The reviewer records a reasoned release/restriction decision under the institution policy. | | Failure or alternate outcome | An outage or missing review cannot be silently treated as a cleared screening result. | No real customer, regulator approval, provider connection or bank operation is asserted. Illustrative amounts have currency INR and scale 2; actual economics/authority must be supplied by the institution. ## Module flow diagrams Read each flow from top to bottom. Rectangles are actions or recorded outcomes; diamonds are decisions; labelled arrows show the next permitted route. The denial route stops the operation. The pending/unknown route keeps the original reference for investigation instead of claiming success. Each diagram corresponds to the numbered journey below. Planned workflows are shown below. Execution depends on confirmed institution policy and interface contracts. ### Flow 1: Receive customer/transaction signal to monitor ```mermaid theme={null} flowchart TD START["B26-J1 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Receive customer/transaction signal"] N0 --> N1 N1["apply approved rules"] N1 --> CHECK{"Policy, reviewer and evidence valid"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N2 N2["create or route case"] N2 --> N3 N3["human review"] N3 --> N4 N4["authorised action"] N4 --> N5 N5["record rationale/report"] N5 --> N6 N6["monitor"] N6 --> RESULT RESULT{"Completion evidence verification"} RESULT -->|Yes| DONE["Record outcome, audit and return"] RESULT -->|Pending or unknown| HOLD["Keep original reference; reconcile status"] HOLD --> REVIEW["Authorised resolution; no blind retry"] ``` ### Flow 2: False positive to update customer-facing state without exposing restricted investigation content ```mermaid theme={null} flowchart TD START["B26-J2 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["False positive"] N0 --> CHECK{"State and approval eligibility"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N1 N1["reviewer validates evidence"] N1 --> N2 N2["approve release/correction"] N2 --> N3 N3["update customer-facing state without exposing restricted investigation content"] N3 --> RESULT RESULT{"Outcome verification"} RESULT -->|Yes| DONE["Record outcome, audit and return"] RESULT -->|Pending or unknown| HOLD["Keep original reference; reconcile status"] HOLD --> REVIEW["Authorised resolution; no blind retry"] ``` ## Required features Planned functionality is listed below. Implementation requires confirmed field definitions, permissions, state transitions and product economics for the selected offering. | Feature | What the user or service does | Completion evidence | | - | - | - | | B26-F1: Onboarding and ongoing screening | Run adopted onboarding/ongoing screening and retain source/version evidence. | A possible match remains distinct from a confirmed case conclusion. | | B26-F2: Real-time fraud signals and step-up/decline policy | Apply approved transaction risk actions and proof escalation at the decision boundary. | Step-up or decline has accountable policy/reason references. | | B26-F3: Transaction monitoring and investigation cases | Assign and investigate monitoring cases with permissioned evidence. | Investigators can trace facts without exposing them to unauthorised roles. | | B26-F4: Suspicious-activity review and controlled filing | Prepare suspicious-activity review and route filing to approved compliance authority. | Submission/acknowledgement status is verified separately from preparation. | | B26-F5: Restriction/appeal handling and policy/model governance | Approve restriction/review/appeal outcomes and govern policy/model changes. | B06 confirms account restrictions and old decisions retain their original policy context. | ## Required configuration Risk scenarios; sanctions screening; monitoring; restrictions; regulatory reporting; review delegation. Store approved values in versioned, effective-dated product/programme policy. Capture the exact configuration version used by an instruction. Missing mandatory configuration blocks the dependent action; enabling a menu cannot grant legal authority. ## End-to-end journey 1 Receive customer/transaction signal → apply approved rules → create or route case → human review → authorised action → record rationale/report → monitor. The journey ends only when its authoritative result, customer/staff-visible result and related book or case history agree. A saved request, queue entry or HTTP acknowledgement is an intermediate state. ## End-to-end journey 2 False positive → reviewer validates evidence → approve release/correction → update customer-facing state without exposing restricted investigation content. Every transition needs an authorised actor, original version and recorded reason where required. Cancellation or client disconnection does not prove server rollback. Financial corrections retain their original reference and use linked reversal/adjustment entries rather than deleting history. ## Interfaces and data dependencies Screening/monitoring contracts; institution policy; case evidence; regulatory submission status. Agree stable institution, product, party and operation references; source version; as-of time; completeness; status/finality; retry rules and correction handling. Where no financial posting occurs, record the administrative/case outcome instead of inventing a journal. All channel requests use server-verified identity and institution scope. Partner, branch and customer access is narrower than institution membership. Lists, details, search, exports, callbacks and files must enforce the same boundary. ## Current implementation and reuse **New Banking project: proposed, not built.** Audit/authorization foundations exist; no AML/fraud decisioning or case engine. Reviewed legacy feature boundaries: `audit`, `staff-audit (traceability foundations only)`. See the source inventory on the [gap page](/banking/current-system-gap). Legacy feature presence is a reuse candidate, not acceptance or deployment evidence for this module. ## Acceptance criteria and exception scenarios Explicit cases: Unavailable screening; false match; conflicting holds; unauthorised investigation access. * Allowed success: confirm saved/output values, authoritative status and the exact approved actor/channel. * Denial: reject foreign institution, unauthorised branch/customer/programme and revoked or expired access without information leakage. * Reliability: prove stale-version rejection and concurrency behaviour; retryable commands apply one economic effect; unknown financial outcomes are reconciled by original reference. * Records and usability: preserve redacted audit, monetary precision and document integrity; verify keyboard/mobile, direct links, expired sessions, Back/Forward and return navigation. Internal web navigation preserves its workspace. Apply the [scenario matrix](/banking/scenario-matrix) and the [shared journey rules](/banking/journeys). Timing, amounts and regulatory applicability are institution-owned inputs, not defaults supplied by this document. ## Required implementation inputs **Status: Pending institution confirmation.** Applicable institution risk policies, jurisdictions, reporting duties and accountable reviewers. Implementation dependencies and approvals are recorded in the [decision register](/banking/decisions). [Module register](/banking/module-register) · [Offering compatibility](/banking/offering-matrix) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.