Standards Alignment

Skill: Standards Alignment

Covers how to find, evaluate, and reference external industry standards within MD-DDL models. No additional spec section is required — standards are referenced in the Reference column of domain summary tables and in entity YAML.

Standards by Domain

How to Apply a Standard Reference

Step 1 — Confirm the mapping exists

Do not silently map a concept to a standard if the fit is approximate. Check that the standard actually defines a counterpart to the entity or attribute being modelled.

For BIAN BOM, use the dedicated guidance in BIAN standard guidance. It defines the deterministic lookup sequence, local reference files for name matching and attribute inspection, candidate disambiguation rules, version parameters, and no-guess policy. Default to BIAN v13 until v14 snapshots are available — see the version selection rules in BIAN standard guidance.

For TM Forum SID, use the dedicated guidance in TM Forum standard guidance. It defines the deterministic lookup sequence, local reference files for entity name matching and property inspection, SID domain taxonomy, the Party/PartyRole pattern, and the Customer vs Subscriber distinction critical for telecoms modelling.

For ACORD, use the curated guidance in ACORD standard guidance. It covers core insurance entities (Policy, Coverage, Claim), party role patterns (PolicyHolder, Insured, Claimant, Beneficiary), ACORD naming conventions, and code lists. Note that ACORD schemas are membership-gated — mappings should note confidence level explicitly.

For ISO 20022, consult the message definition catalogue for the relevant message type.

For HL7 FHIR, use the dedicated guidance in FHIR standard guidance. It defines a deterministic lookup sequence using local cache files for resource and terminology mapping before falling back to live FHIR pages.

Step 2 — Note material differences

If the standard's definition differs from the user's intent, say so explicitly:

"In BIAN BOM, 'Party' is defined as [standard definition]. Your usage adds [X]. This is close enough to reference BIAN, but we should note the extension in the entity description."

Step 3 — Format the reference link

Use the Reference column in summary tables and in entity descriptions:

| `Customer` (`entities/customer.md#customer`) | `Party Role` (`entities/party_role.md#party-role`) | A Party with an active product relationship. | `BIAN BOM - Party Role` (`https://bian-modelapi-v4.azurewebsites.net/BOClassByName/PartyRole`) |

For multiple applicable standards, list the most specific first.

Step 4 — Carry references into metadata

When a regulatory standard applies to the domain, add it to regulatory_scope in the domain YAML — not just to the Reference column:

regulatory_scope:
  - GDPR
  - BCBS 239
  - APRA CPS 234

Approximate vs. Exact Mapping

Never fabricate a reference URL to make the model look more aligned than it is. A missing reference is honest; a wrong one is harmful.

For BIAN specifics (including local reference files, lookup order and exact-name resolution), follow BIAN standard guidance. For TM Forum SID specifics (including SID domain taxonomy and Party/Customer/Subscriber patterns), follow TM Forum standard guidance. For ACORD specifics (including insurance entity hierarchies and party role patterns), follow ACORD standard guidance. For FHIR specifics (including resource and terminology cache files and healthcare mapping patterns), follow FHIR standard guidance.

Standard Reconciliation Protocol

Use this protocol when the user's model decomposition and the standard's decomposition genuinely differ — not just in naming, but in how concepts are split, merged, or specialised. This is common when an organisation has evolved its own terminology or when the standard is more abstract than the user's model.

When to Trigger

Trigger reconciliation when any of these occur:

• User's single concept maps to multiple standard objects (split)
• Multiple user concepts map to a single standard object (merge)
• User concept and standard object overlap partially with distinct extensions
• User asks "how does our model relate to [standard]?" in structural terms

Step 1 — Build the Comparison Table

Present a structured side-by-side to the user:

Your Model | Standard | Overlap | Gap | Options
--- | --- | --- | --- | ---
Customer | BIAN Party Role | Both represent a business relationship to the organisation | Your Customer includes identity (name, DOB); BIAN separates identity into Party | (a) Split into Party + Customer Role (b) Keep Customer, reference BIAN Party Role with note
Account Holder | BIAN Party Role | Both represent a party acting in a capacity | Your Account Holder is a specialisation of Customer; BIAN treats both as Party Role subtypes | (a) Model as separate entity specialising Party Role (b) Treat as Customer attribute

Step 2 — Evaluate Each Option

For each row, apply these decision criteria:

Step 3 — Propose a Resolution

For each row, recommend one of:

Step 4 — Document the Decision

For each resolved concept, produce an annotation in the entity description that records the reconciliation:

### Customer
The party with an active product or service relationship.

**Standards reconciliation:**
- BIAN equivalent: Party Role (partial alignment — BIAN separates identity
  into Party; our Customer carries identity attributes directly)
- Decision: Kept as single entity; reference BIAN Party Role with qualification
- Rationale: Customer team owns both identity and relationship data; splitting
  would fragment operational ownership

This makes the alignment decision auditable and prevents future contributors from re-asking the same question.

Worked Example: BIAN Alignment for Financial Crime

This example demonstrates the standards alignment process applied to core entities from the examples/Financial Crime/ domain, mapping against the BIAN Business Object Model (v13 — current production baseline; v14 pending snapshot availability).

Step 1 — Identify candidate mappings

Step 2 — Evaluate differences

Step 3 — Resolution

Step 4 — Resulting Reference column entries

Entity | Reference
--- | ---
Party | BIAN BOM - Party
Person | BIAN BOM - IndividualEntity
Company | BIAN BOM - Organisation
Party Role | BIAN BOM - PartyRole
Customer | BIAN BOM - CustomerRole
Transaction | BIAN BOM - AccountEntry (partial — Transaction extends beyond ledger movements to include payment roles and initiator context)

Key takeaway

Not every entity maps 1:1 to a standard. Transaction → AccountEntry is a legitimate partial alignment. The reconciliation note ensures future contributors understand why the mapping is qualified rather than exact.

Regulatory Metadata Prompt

When a domain's regulatory_scope is being populated, prompt the user with this checklist. Many teams underspecify this because they assume "someone else handles compliance."

• Does this domain hold personal data about individuals? → GDPR / CCPA / PDPA
• Does this domain support financial reporting? → SOX / BCBS 239
• Does this domain hold transaction or payment data? → PCI DSS / AML / FATF
• Does this domain support credit risk assessment? → Basel III
• Does this domain hold health information? → HIPAA / HL7
• Is the institution regulated in Australia? → APRA CPS 234 / CPG 235
• Is the institution regulated in the EU? → DORA / EU 5AMLD / 6AMLD
• Is the institution regulated in the UK? → FCA COBS / SYSC

For each applicable framework, confirm with the user whether it affects:

• The classification or pii flags
• The default_retention value
• Any specific attribute-level governance (e.g., credit scores under ECOA)