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** <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.
\ No newline at end of file