From 440c0e8457b277d3c44728067290b3a452b6efa1 Mon Sep 17 00:00:00 2001 From: Paul Atkin Date: Wed, 1 Jul 2026 10:18:06 +0000 Subject: [PATCH] Add fii --- fii | 116 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 116 insertions(+) create mode 100644 fii diff --git a/fii b/fii new file mode 100644 index 0000000..1897c0d --- /dev/null +++ b/fii @@ -0,0 +1,116 @@ +When data modeling for **Financial Crime Screening Case Management & Case Outcomes** using the BIAN Business Object Model (BOM), you operate at the intersection of operational screening, risk evaluation, and formal case lifecycle tracking. + +In BIAN, screening triggers generate investigations managed via specific control records and core foundational entities. The primary candidate BOM entities to include for your designated processes are outlined below. + +--- + +## 1. Core Case Management & Outcome Entities + +These entities form the structural backbone for tracking an investigation from a screening alert to its legal or operational resolution. + +* **Case / Investigation Case:** The foundational entity representing the ongoing investigation record. It encapsulates the status, history, and metadata of the investigation. +* **Fraud/AML Resolution Procedure (Control Record):** In BIAN, Service Domains operate on Control Records. For financial crime, this specialized control record tracks the state, execution tasks, and dynamic workflow of the individual case investigation. +* **Case Evidence / Investigation Evidence:** Used to aggregate data points (e.g., transaction records, communication logs, external match data) supporting or clearing the case. +* **Regulatory Report / Suspicious Activity Report (SAR):** The entity representing the formalized payload sent to financial intelligence units (e.g., FIU, FinCEN) as a regulatory case outcome. +* **Case Resolution / Case Disposition:** Captures the final decision, logic justification, and operational outcome (e.g., *False Positive, Confirmed Fraud, True Match - Block Account*). + +--- + +## 2. Process-Specific Mapping to BOM Entities + +The screening processes you highlighted map to specific BIAN BOM domain clusters: + +### Prescribed Transaction Processing (PTR) & Transaction Monitoring (TMR) + +These processes rely heavily on analyzing transaction footprints against historical baseline behavior. + +* **Financial Transaction / Payment Transaction:** The root execution entity being monitored or held. +* **Transaction Alert / Rule Occurrence:** The structural entity generated when a TMR scenario threshold or a PTR mandate is breached. It acts as the direct instantiation link to a new or existing *Case*. +* **Customer/Account Behavior Profile:** Houses historical transaction baselines used by TMR engine rules to flag statistical anomalies. + +### Customer Risk Scoring Model (CRSM) + +* **Party Risk Profile / KYC Profile:** A sub-component of the master `Party` entity. It maintains the calculated risk tier, risk indicators, score history, and the reference to the underlying scoring model version used. +* **Risk Assessment Event:** Represents the point-in-time calculation event when a customer's risk profile is re-evaluated. + +### Customer Sanctions & Payment Sanctions + +* **Sanctions List / Watchlist:** The reference entity representing internal or external data sets (e.g., OFAC, UN, EU lists) against which names and entities are checked. +* **Watchlist Match / Hit:** The entity capturing the specific metadata of a match (e.g., confidence score, matched attributes like DOB or address) between a `Party` (or payment counterparty) and a `Sanctions List Entry`. +* **Party / Politically Exposed Person (PEP) Status:** Structural attributes and status logs associated with the core `Party` entity identifying specialized risk classifications. + +--- + +## 3. High-Level Entity Relationship Traceability + +When structuring your logical data model, ensure the following relationship flow is clear: + +``` +[Transaction Alert / Watchlist Match] + │ + ▼ (triggers) +[Fraud/AML Resolution Procedure (Control Record)] ───► Contains: [Case Evidence] + │ + ▼ (concludes with) +[Case Resolution / Disposition] + │ + ▼ (if True Positive, generates) +[Regulatory Report (SAR)] + +``` + +* **Party (Customer) / Account:** Always linked at the center, ensuring that historical case outcomes dynamically feed back into the **Party Risk Profile** for future CRSM recalculations. + +To implement these candidates into an official BIAN-compliant architecture, these BOM (Business Object Model) entities directly tie to standard **BIAN Service Domains** and official functional terminology. + +The exact mapping to BIAN 12.0 reference framework concepts is detailed below. + +--- + +## 1. Core Case Management & Outcomes Reference + +| Selected Candidate BOM Entity | BIAN Semantic Mapping & Object Type | Primary Mapping Service Domain (SD) | +| --- | --- | --- | +| **Fraud/AML Resolution Procedure** | **Control Record**
+ +
*(Tracks the lifecycle/execution of the investigation)* | **Fraud Resolution**
+ +
*(Operates on the Fraud Case Resolution Procedure Control Record)* | +| **Case / Investigation Case** | **Asset / Log**
+ +
*(The structural record of the dispute or anomaly)* | **Case Management**
+ +
*(Generic or domain-specific variant)* | +| **Case Evidence** | **Data Object / Asset**
+ +
*(The aggregate forensic and contextual payload)* | **Fraud Resolution** / **Case Management** | +| **Case Resolution / Disposition** | **State / Configuration Attribute**
+ +
*(The final determination or closing status)* | **Fraud Resolution** *(Decision outcome phase)* | +| **Regulatory Report / SAR** | **Document / Regulatory Payload**
+ +
*(The structured external transmission format)* | **Regulatory Compliance**
+ +
*(Manages official regulatory filings and disclosures)* | + +--- + +## 2. Screening Processes-Specific Reference + +| Process | Candidate BOM Entity | Primary BIAN Service Domain (SD) Mapping | BIAN BOM Functional Context | +| --- | --- | --- | --- | +| **TMR / PTR** | Financial / Payment Transaction | **Payment Execution**
+ +
*(or relevant Transaction/Product domains)* | The underlying core asset entity that triggers processing or undergoes post-execution evaluation. | +| **TMR / PTR** | Transaction Alert / Rule Occurrence | **Fraud Evaluation** | Evaluates real-time, near-real-time, or batch transactions against heuristic or statistical rules to emit an alert event. | +| **CRSM** | Party Risk Profile / KYC Profile | **Party Lifecycle Management** | Houses the *Party Risk Assessment Profile* and operational classification attributes. | +| **CRSM** | Risk Assessment Event | **Party Data Management** / **Fraud Evaluation** | The programmatic trigger that recalculates scoring parameters. | +| **Sanctions** | Sanctions List / Watchlist | **Document Directory** / **Regulatory Compliance** | External reference data ingested and versioned as standard lookup matrices. | +| **Sanctions** | Watchlist Match / Hit | **Party Screening** | The explicit Service Domain optimized for scanning parties, names, and structured strings against reference lists to return a match percentage. | + +--- + +> ### 💡 Design Note for BIAN Architecture +> +> +> In BIAN's **ISO 20022 alignment**, whenever a `Payment Execution` or `Corporate Operational Clearing` transaction hits a blocker via **Party Screening** or **Fraud Evaluation**, the process orchestrates an asynchronous call to establish a new *Control Record Instance* within **Fraud Resolution**. All evidence gathered during automated lookups is logged within this instance before graduating to a final state change or external `Regulatory Compliance` notification. \ No newline at end of file