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.