Add fii
This commit is contained in:
@@ -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** <br>
|
||||
|
||||
<br>*(Tracks the lifecycle/execution of the investigation)* | **Fraud Resolution** <br>
|
||||
|
||||
<br>*(Operates on the Fraud Case Resolution Procedure Control Record)* |
|
||||
| **Case / Investigation Case** | **Asset / Log** <br>
|
||||
|
||||
<br>*(The structural record of the dispute or anomaly)* | **Case Management** <br>
|
||||
|
||||
<br>*(Generic or domain-specific variant)* |
|
||||
| **Case Evidence** | **Data Object / Asset** <br>
|
||||
|
||||
<br>*(The aggregate forensic and contextual payload)* | **Fraud Resolution** / **Case Management** |
|
||||
| **Case Resolution / Disposition** | **State / Configuration Attribute** <br>
|
||||
|
||||
<br>*(The final determination or closing status)* | **Fraud Resolution** *(Decision outcome phase)* |
|
||||
| **Regulatory Report / SAR** | **Document / Regulatory Payload** <br>
|
||||
|
||||
<br>*(The structured external transmission format)* | **Regulatory Compliance** <br>
|
||||
|
||||
<br>*(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** <br>
|
||||
|
||||
<br>*(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.
|
||||
Reference in New Issue
Block a user