A counterparty-risk investigation at a large financial institution does not begin with a question about a counterparty. It begins with the institution rebuilding its understanding of the counterparty from data scattered across systems that were never designed to be queried together. Transaction systems hold the volume picture. KYC platforms hold the documentation picture. Sanctions screening tools hold the watchlist-match picture. News and adverse-media feeds hold the reputational picture. Each system has its own identifier scheme, its own refresh cadence, its own data-quality posture, and its own access-control model. The analyst’s first task is not analysis. It is stitching.
This integration cost is the structural problem the ontology layer solves. An ontology is the abstraction between source-system schemas and analytical workflow — a stable model of the entities and relationships that matter to the investigation, projected from whichever upstream systems are current, decoupled from the schema churn those upstream systems will inevitably produce over the life of the engagement. Palantir Foundry’s ontology layer is the most operationally mature commercial implementation of this pattern, and its design decisions determine whether a Foundry-based DD workflow remains accurate as the institution’s source systems change underneath it.
This article walks the ontology-design patterns for counterparty-risk investigations. The object-type taxonomy that captures the entities the investigator reasons about; the link-type design that turns relationships into first-class data; the way the ontology layer interacts with the four other Foundry primitives that complete the workflow (Pipeline Builder for ingestion, Workshop for the investigator surface, Actions for state changes, AIP for analytical augmentation); the audit-trail discipline that makes the resulting decisions defensible to a regulator; and — equally important — the conditions under which a Foundry-based architecture is not the right answer.
The counterparty-risk problem at institutional scale
A mid-size advisory firm with twenty counterparties under continuous monitoring can run its DD workflow on a shared spreadsheet. A regional bank with two thousand counterparties needs structure. A global bank with two hundred thousand counterparties across forty jurisdictions, with three regulatory regimes governing the same beneficial-ownership relationship, with KYC refresh requirements that vary by counterparty type and jurisdiction, with multiple acquired subsidiaries each carrying its own legacy counterparty system — that bank does not have a workflow problem. It has a data-substrate problem.
The substrate problem manifests in three operational ways. Recurring rework: every new engagement re-stitches the same source systems because no durable abstraction sits between them. Stale views: the analyst’s counterparty picture lags the latest source-system updates by hours, days, or — for the systems with quarterly refresh cycles — months. Loss of historical context: when the analyst needs to answer “what did we know about this counterparty at the time of the transaction in question,” the answer requires reconstructing prior source-system states that the institution may no longer have.
A data warehouse alone does not solve these problems. A warehouse standardizes the storage of source data but does not abstract the relationships between entities. An investigator opening a counterparty view in a warehouse-backed BI tool still sees rows from different source tables joined by identifier-matching heuristics that may or may not be current. The ontology layer is the abstraction that converts “rows in tables” into “objects with stable identifiers and explicit relationships.”
The ontology layer
A Foundry ontology consists of object types (categories of entities — Counterparty, Person, Transaction, SanctionsHit), object instances (the specific entities of each type), properties (attributes on each instance), and link types (the relationships between objects). An object type is defined once and resolves dynamically: its properties come from underlying datasets produced by Pipeline Builder transforms; its identity is stable across source-system changes; its relationships to other objects are first-class data that the analytical workflow can query directly.
The design discipline matters more than the platform mechanics. Three principles govern an effective DD ontology.
Stability over expressiveness. An ontology that captures every possible attribute of every entity becomes unmaintainable; an ontology that captures only the attributes the investigator actually uses for decisions stays clean. The right cut is conservative — start with the minimum object types and properties that support the engagement workflow, and add specificity only when an actual workflow demands it.
Relationships as first-class data. A link from a Counterparty to its ultimate beneficial owner is not a foreign-key reference; it is an object in its own right, with properties (ownership percentage, effective-from and effective-to dates, disclosure source) and lifecycle (creation, supersession, termination). Treating relationships as data is what allows the analyst to query “which counterparties had this Person as a UBO at the time of this transaction” — a question that a foreign-key model cannot answer compactly.
Audit metadata on everything. Every object and every link carries metadata that traces it back to the source system, the extract date, and the transform version that produced it. This is not optional. It is the precondition for the audit-trail discipline that downstream regulators will examine.
Object-type design
Object-type design for a counterparty-risk-investigation ontology converges on a small set of central types with subtypes absorbing the heterogeneity. The three central types are Counterparty, Person, and Transaction; the supporting types are SanctionsHit, AdverseMediaMention, NewsArticle, KYCDocument, and RegulatoryFiling. Concretely:
The block below is illustrative ontology-schema notation, not literal Foundry config syntax. Foundry ontology objects are created through the Ontology Manager UI or the Foundry SDK, not via direct YAML ingest; the schema notation here documents shape and intent. The companion DD Tech Lab repository at https://github.com/noahrgreen/dd-tech-lab-companion ships a parseable equivalent at articles/001_foundry_ontology_counterparty_risk/ontology_schema/counterparty_risk_ontology.yaml (verifiable via yaml.safe_load) and Python dataclass equivalents at foundry_sdk_stubs/ontology_classes.py that any reader can run locally to materialize the worked example.
ObjectTypes:
Counterparty:
Properties:
counterparty_id: primary_key
legal_name: string
jurisdiction: country_code
risk_rating: enum[low, medium, high, critical]
last_kyc_refresh: timestamp
pipeline_run_id: string # audit-metadata: traces back to ingestion run
source_extract_date: timestamp
Subtypes:
CorporateCounterparty:
adds: [entity_type, incorporation_date, parent_entity_id]
IndividualCounterparty:
adds: [date_of_birth, nationality, pep_status]
FundCounterparty:
adds: [investment_manager_id, fund_structure_type]
Person:
Properties:
person_id: primary_key
legal_name_canonical: string # entity-resolution canonical form
legal_name_variants: array<string> # all observed transliterations
date_of_birth: date | null
nationality: array<country_code>
pep_status: enum[none, domestic, foreign, international_org] | null
Transaction:
Properties:
transaction_id: primary_key
source_counterparty_id: foreign_key(Counterparty)
dest_counterparty_id: foreign_key(Counterparty)
amount: decimal
currency: iso_currency
timestamp: timestamp
settlement_state: enum[pending, settled, reversed]
Subtypes:
FXTransaction: adds: [base_pair, quote_pair, rate]
SecuritiesTransaction: adds: [instrument_id, trade_type]
PaymentTransaction: adds: [payment_method, beneficiary_bank]
LendingTransaction: adds: [facility_id, drawdown_type]
SanctionsHit:
Properties:
sanctions_hit_id: primary_key
counterparty_id: foreign_key(Counterparty)
sanctions_list_id: string # OFAC SDN, EU Consolidated, UK HMT, etc.
hit_type: enum[exact_match, fuzzy_match, alias_match]
effective_from: timestamp
effective_to: timestamp | nullThe design discipline is conservative on what gets added to the ontology and aggressive on the audit-metadata columns. Every property has a defensible workflow use; every object instance traces back to the pipeline run and source-extract date that produced it. Subtypes absorb heterogeneity that would otherwise force the parent type to carry optional properties for every variant; the property-resolution layer underneath Foundry handles the projection from source-system schemas into subtype-specific instances.
Person is intentionally distinct from IndividualCounterparty. A Person becomes an IndividualCounterparty only when the institution transacts directly with that natural person; most Persons appear in the ontology only as UBO or officer links to entity Counterparties, and that role asymmetry justifies the separate type.
Link-type design
Link-type design is where the ontology earns its keep operationally. The investigator’s workflow is not “look at one object”; it is “navigate from the counterparty through its relationships to assemble the assessment.” Two representative link types make the pattern concrete:
LinkTypes:
UltimateBeneficialOwner:
source: Counterparty
target: Person
Properties:
ownership_percentage: decimal # 0.00–1.00
ownership_type: enum[direct_voting, direct_economic, indirect_calculated]
effective_from: date
effective_to: date | null # null = still effective
disclosure_source: enum[fincen_boi, uk_psc, eu_ubo, opencorporates, voluntary]
disclosure_date: date
TransactedWith:
source: Counterparty
target: Counterparty
Properties:
aggregated_volume_usd: decimal # rolling 365-day aggregation
aggregated_count: integer
last_transaction_date: timestamp
direction: enum[bilateral, source_to_dest_only, dest_to_source_only]The remaining four core link types — SanctionsHit, AdverseMediaMention, OfficerOf, RegisteredIn — follow the same pattern: source and target object types, properties that carry first-class data, and effective-date bounds for temporal queries.
Temporal bounds matter for two reasons. First, the regulator’s reconstructive query — “what was the ownership structure on date D” — requires every link to carry effective-from / effective-to bounds rather than a single “current state” snapshot. Second, indirect ownership calculations require the system to know which links were simultaneously effective during the relevant period. The cumulative ownership of a Person over a Counterparty across a chain of intermediate entities is the product of direct ownership percentages along the path:
$$\text{cumulative\_ownership}(P, C) = \sum_{p \,\in\, \text{paths}(P \to C)} \;\; \prod_{e \,\in\, p} \text{pct}(e)$$
where $\text{pct}(e)$ is the ownership_percentage property on each OWNS edge $e$, $\text{paths}(P \to C)$ ranges over all distinct simple ownership paths from Person $P$ to target Counterparty $C$, and edges along each path must be simultaneously effective at the query date — that is, each edge’s effective_from and effective_to interval must contain the query date for the path to count.
A small example: suppose Person $P$ owns 51% of intermediate Entity $E_1$, which owns 80% of target Counterparty $C$, and $P$ also owns 60% of intermediate Entity $E_2$, which owns 30% of $C$, with $E_1$ and $E_2$ being entirely distinct ownership chains (no shared intermediate entities). Two distinct simple paths contribute:
- Path 1: $P \to E_1 \to C$, product = \$0.51 \times 0.80 = 0.408$
- Path 2: $P \to E_2 \to C$, product = \$0.60 \times 0.30 = 0.180$
- Cumulative ownership = \$0.408 + 0.180 = 0.588$ (58.8%)
Anti-double-counting requirement: paths that share an intermediate entity (e.g., two paths from $P$ through $E_1$ to $C$ via different sub-chains) must not be summed without deduplicating the shared edge — the shared ownership interest contributes once, not once per path. In practice, the graph traversal must enumerate distinct simple paths (no repeated nodes) AND deduplicate by edge identity / legal ownership interest before summation; standard graph algorithms over the OWNS relationship type implement this discipline.
The regulatory thresholds (typically 25% under FinCEN BOI [31 CFR §1010.380; verify current rule status as of publication — Treasury / FinCEN’s 2025 interim final rule revised reporting obligations and the practitioner should confirm current applicability before relying on cited thresholds], 25% under UK PSC under Companies Act 2006, 25% under FATF Recommendation 24 (March 2022 revision)) apply to this cumulative figure, not to any single direct link. Beneficial-ownership analysis under FinCEN BOI also includes a substantial control test separate from the percentage threshold; a Person below the 25% ownership level may still be reportable through control rights (board appointment authority, senior-officer status, substantial influence over major decisions). The ontology link types should capture control relationships separately from ownership-percentage relationships to support this distinct analysis. Without first-class temporal bounds on each OWNS edge, the query “what was the cumulative ownership on the date of the transaction in question” cannot be answered reliably.
A link type with first-class properties is therefore a different beast from a foreign-key reference. It supports the temporal query patterns the investigator needs, the provenance documentation regulators require, and the indirect-ownership arithmetic the BOI compliance regime mandates. All three are out of reach for a foreign-key model that captures only present-state relationships without lifecycle metadata.
How ontology, Workshop, Actions, and AIP fit together
The ontology layer is data infrastructure; on its own, it does not produce investigator workflow. Four other Foundry primitives complete the system, each handling a specific aspect of the analyst’s working life.
Pipeline Builder ingests data from source systems and projects it into ontology object instances and links. This is the layer where source-schema changes are absorbed — a bronze (raw source) → silver (conformed) → gold (ontology-ready) pattern that decouples the analytical workflow from upstream schema churn.
Workshop is the investigator’s surface — the application where the analyst opens a counterparty card, navigates its links, reviews its history, and decides whether to escalate. Workshop applications consume ontology objects and present them in role-tuned layouts; the single-pane-of-glass discipline eliminates the alt-tab-across-five-tools cost that the data-substrate problem otherwise imposes.
The Actions framework captures every state change the investigator initiates. Elevating a counterparty’s risk rating, dismissing a sanctions hit, opening an enhanced-due-diligence engagement — each of these is an Action that validates the inputs, executes the side effects, and creates an immutable AuditEntry that ties the change to the analyst, the supporting evidence, and the timestamp.
AIP — Palantir’s LLM orchestration layer — provides analytical augmentation grounded to the ontology. The canonical use case is adverse-media summarization: given the AdverseMediaMention objects linked to a Counterparty, generate a 200-word risk-rating-relevant synthesis with citations to the source mentions. The grounding-and-citation pattern is essential — AIP can be configured to require citations for every factual assertion, and a properly-implemented adverse-media-summary application should reject outputs that fail this constraint. Citation enforcement is an application-design decision, not an automatic AIP property; institutions deploying AIP in regulatory-defensible workflows must verify the grounding configuration and validate against a labeled holdout set before production use.
The four primitives compose. The ontology is the noun layer; Pipeline Builder maintains it; Workshop reads it; Actions write to it; AIP enriches it. None of the four is useful in isolation, but together they form the workflow the institutional DD function actually needs.
A worked counterparty-risk investigation
Consider a synthetic counterparty — a corporate entity registered in Jurisdiction Z, two ownership hops from its ultimate beneficial owner, with three adverse-media mentions in the trailing 90 days and a current risk rating of medium. The ontology objects that constitute its current state:
# Synthetic ontology state for the worked example
counterparty = Counterparty(
counterparty_id="C-SYN-12345",
legal_name="ACME Holdings (Z)",
jurisdiction="ZZ",
risk_rating="medium",
last_kyc_refresh="2026-02-14T00:00:00Z",
pipeline_run_id="prod-2026-05-11T03:00:00Z-run-4821",
source_extract_date="2026-05-11T02:14:00Z",
)
ubo_person = Person(
person_id="P-SYN-08832",
legal_name_canonical="<synthetic name>",
nationality=["ZZ"],
pep_status="none",
)
ubo_link = UltimateBeneficialOwner(
source=counterparty, target=ubo_person,
ownership_percentage=0.408, # 0.51 * 0.80, two-hop chain
ownership_type="indirect_calculated",
effective_from="2024-03-01",
effective_to=None,
disclosure_source="fincen_boi",
disclosure_date="2024-03-15",
)
adverse_media_mentions = [
AdverseMediaMention(amm_id="AMM-1", counterparty_id=counterparty.counterparty_id,
mention_date="2026-04-22", risk_relevance="high"),
AdverseMediaMention(amm_id="AMM-2", counterparty_id=counterparty.counterparty_id,
mention_date="2026-04-30", risk_relevance="medium"),
AdverseMediaMention(amm_id="AMM-3", counterparty_id=counterparty.counterparty_id,
mention_date="2026-05-08", risk_relevance="high"),
]
sanctions_hits = [] # no active sanctions exposure(Note on code conventions: ontology object types — Counterparty, Person, UltimateBeneficialOwner, etc. — are Foundry-platform-defined classes whose runtime implementation lives in the platform’s ontology layer rather than in user code. The snippets shown here are illustrative of the data shape; the companion repository’s foundry_sdk_stubs/ontology_classes.py provides plain-Python dataclass representations of the same shapes, and run_worked_example.py runs the full worked-example walkthrough end-to-end with stdlib only — readers can reproduce the example before applying it to an actual Foundry deployment.)
The investigator opens the Counterparty’s Workshop card. The header surfaces the four core properties (legal name, jurisdiction, risk rating, last KYC refresh). Below the header, AIP generates a 180-word summary grounded to the three AdverseMediaMention objects above; in this institution’s deployment, the AIP application is configured to require an inline citation to a specific source article for every factual assertion (the grounding pattern is mandatory in the institution’s prompt + validation layer, not an automatic AIP property — outputs that fail the citation check are rejected by the application before reaching the investigator). The relationships section surfaces the cumulative beneficial-owner calculation (40.8% indirect via the two-hop chain to this Person under this single ownership path; note this worked-example synthetic counterparty has one direct chain, distinct from the two-path 58.8% illustration in the earlier math section) and the empty sanctions-hit list. The investigator concludes the adverse-media coverage warrants elevation.
The investigator invokes the ElevateRiskRating Action. The Action call is itself a structured operation:
ElevateRiskRating(
target=counterparty,
new_risk_rating="high",
justification=(
"Three adverse-media mentions in trailing 90 days, two flagged "
"high-risk-relevance under AIP grounding (AMM-1, AMM-3). "
"Pattern consistent with material reputational exposure warranting "
"enhanced due diligence under the institution's CDD/EDD framework "
"as informed by the FFIEC BSA/AML Examination Manual."
),
supporting_evidence=ObjectSet(adverse_media_mentions),
)
# Side effects:
# counterparty.risk_rating: "medium" -> "high"
# counterparty.last_risk_change: 2026-05-11T14:32:18Z
# Created:
# AuditEntry(
# action_type="ElevateRiskRating",
# actor="<investigator_id>",
# actor_role="senior_analyst",
# timestamp=2026-05-11T14:32:18Z,
# target_id=counterparty.counterparty_id,
# prior_state={"risk_rating": "medium"},
# new_state={"risk_rating": "high"},
# justification=<text above>,
# supporting_evidence_ids=["AMM-1", "AMM-2", "AMM-3"],
# immutable=True,
# )
# Post-execution hook: notify compliance_committee_distribution_listA regulator examining the engagement six months later queries the AuditEntry object class for all Counterparty rating changes in the period, filters to this counterparty, and retrieves the full lineage — actor, timestamp, justification, and supporting-evidence chain. The immutability guarantee on AuditEntry ensures the audit log has not been altered after the fact; the supporting-evidence references resolve to the same AdverseMediaMention objects the investigator reviewed, time-locked to their state at the time of the Action.
Audit-trail discipline
The institution should treat the Actions framework as the only sanctioned path for state-changing operations in its DD workflow. This is not a platform-enforced guarantee — Foundry provides the primitives, but the discipline is an institutional implementation requirement. The implementation has three layers.
Append-only audit object discipline. The institution models an AuditEntry object type (or equivalent audit-log dataset) that records every Action invocation. The discipline is that entries are written once, never edited, and superseded only by later entries that explicitly reference the prior — a supersession pattern rather than edit/delete. Enforcement: permissioned write paths constraining AuditEntry writes to Action side-effects only; retention policy preventing deletion; periodic control testing that samples for unsanctioned writes.
Action-scope enforcement. The Actions framework constrains state changes only when ALL production write paths route through Actions or through equivalently controlled service accounts. Direct dataset edits, privileged transform changes, manual CSV imports, retrospective fixes, admin overrides, and transform redeployments are bypass channels. Each bypass channel requires its own audit treatment — typically a separate change-management log, dual-approval gating, or post-hoc reconciliation to the Action-mediated record. Institutions that do not address bypass channels produce audit trails that are complete only within the Action surface — and incomplete for the operations regulators are most likely to scrutinize.
Platform audit-log reconciliation. Foundry’s platform-level audit logs (separate from the institution’s AuditEntry ontology object) capture lower-level events: dataset access, transform deployment, user sign-in, permission changes. The institution’s regulatory-evidence package should reconcile the ontology-level AuditEntry record against the platform audit log; gaps between the two indicate bypass-channel usage or platform-side events without ontology-level reflection.
Documented this way, the audit-trail discipline is consistent with the documentation expectations in SR 11-7, OCC Bulletin 2011-12, SOX §404 internal-controls framing, and the FFIEC BSA/AML Examination Manual’s CDD/EDD documentation language. Whether any specific control configuration satisfies any specific regulator’s expectations is a fact-specific determination that depends on the institution’s overall control environment, the products and counterparties involved, and the examiner’s interpretation — not a property the platform delivers automatically.
Where Foundry’s value falls off
Foundry is not the right answer for every DD operation. Five conditions reliably indicate a different architecture serves better.
Small scale. A DD shop with one investigator, fifty counterparties, and quarterly engagement cycles will not extract enough leverage from an ontology layer to justify the platform investment. A well-structured spreadsheet, a shared knowledge base, and disciplined manual workflow produce comparable outcomes at a fraction of the operating cost.
ML-modeling-centric workflows. Institutions whose DD work is dominated by machine-learning model development and retraining — fraud-detection models, AML transaction-monitoring models, credit-risk models — typically find Databricks’ notebook-first lakehouse environment a better fit. Foundry can host these workloads, but its design center is the investigator-workflow surface, not the data-science iteration loop.
Pure-warehouse use cases. Institutions whose DD analytics is fundamentally a reporting problem — known queries, scheduled dashboards, regulatory submissions — without an investigator-driven exploratory workflow may find Snowflake plus DBT plus a custom application layer more cost-effective. The ontology layer earns its keep when the investigator workflow drives the analytical questions; if the analytical questions are pre-defined, the warehouse-first stack delivers the answers without the ontology overhead.
Insufficient operating maturity to govern the platform. Foundry rewards institutions that can sustain ontology stewardship (a dedicated owner for each object type), access governance (RBAC tuned to investigator role and data-classification tier), deployment governance (CI/CD for transforms and Workshop applications), and platform-specialist staffing (engineers fluent in Foundry’s specific abstractions, not just generic data engineering). Institutions that cannot resource these disciplines will produce a Foundry deployment that decays into the same fragmented state the platform was supposed to solve — except now with vendor lock-in cost layered on top.
Procurement / security / vendor-risk constraints. Some institutions cannot or will not adopt Foundry for reasons independent of architectural fit: vendor-risk-management posture preferring established cloud-warehouse vendors, data-residency requirements Foundry’s commercial-cloud deployment cannot satisfy, existing-cloud standardization mandates (AWS-only, Azure-only) that conflict with Palantir’s deployment model, or procurement policies requiring open-source-base components. The architecture comparison is moot when the procurement layer blocks adoption.
The honest answer is that Foundry’s value scales with three factors: institutional complexity, regulatory burden, and the degree to which multiple engagements must coordinate against a shared counterparty substrate. Where all three are high — AND the institution can resource platform governance, AND procurement / vendor-risk constraints permit adoption — Foundry’s ontology layer becomes load-bearing infrastructure. Where any of those preconditions falls, simpler architectures or alternative platforms serve better.
The sub-series ahead
This article established the ontology layer as the foundation of a Foundry-based DD workflow. The remaining nine articles in this sub-series build out the operational primitives that surround it.
The Pipeline Builder for DD Data Ingestion: Connecting Bank-Internal Systems to the Ontology Layer article walks Pipeline Builder for source-to-ontology ingestion. The forthcoming Workshop Application Patterns for DD Engagements article covers Workshop application patterns for investigator surfaces. The forthcoming AIP-Driven Adverse-Media Summarization article walks AIP-driven adverse-media summarization with its grounding-and-citation discipline. The forthcoming Actions Framework for Audit-Trail Discipline article covers the Actions framework for audit-trail compliance. The forthcoming Foundry Code Repositories: Python and PySpark for DD article addresses the Code Repositories pattern for transforms that exceed Pipeline Builder’s no-code envelope. The forthcoming Quiver for Ad-Hoc Counterparty Queries article covers Quiver for ad-hoc investigator queries. The forthcoming Time-Series for Counterparty Risk Trajectories article walks time-series modeling for counterparty risk trajectories. The forthcoming Ontology for Beneficial-Ownership Networks article takes the ontology pattern to bank-group-scale beneficial-ownership networks with cross-jurisdictional disclosure-regime modeling. The forthcoming Foundry vs Snowflake/DBT vs Databricks: A DD-Lens Comparison article closes the sub-series with the platform-architecture comparison framework that places Foundry against Snowflake + DBT and Databricks alternatives.
Reproducible artifacts for each article — schema YAML, transform code, Workshop module specifications, AIP prompts, Action templates — ship in the companion DD Tech Lab repository at https://github.com/noahrgreen/dd-tech-lab-companion. For this article, the initial artifact bundle is published at articles/001_foundry_ontology_counterparty_risk/: the ontology schema as parseable YAML (verifiable via yaml.safe_load), the synthetic worked-example dataset as CSV, the Python dataclass stubs plus an end-to-end run_worked_example.py script that reproduces the article’s walkthrough using only the Python standard library, the Workshop module JSON spec, and the ElevateRiskRating ActionType template YAML. Subsequent articles ship their artifacts alongside their publication at the same repository.
Authority:
Palantir Foundry documentation:
- Foundry Documentation — Ontology (object types, link types, properties, audit metadata)
- Foundry Documentation — Pipeline Builder, Workshop, Actions framework, AIP, Code Repositories, Quiver, Time Series
Regulatory framework:
- Federal Reserve, SR 11-7 — Guidance on Model Risk Management
- OCC Bulletin 2011-12 — Sound Practices for Model Risk Management
- SOX §404 — Management Assessment of Internal Controls
- FFIEC, BSA/AML Examination Manual (Customer Due Diligence, Enhanced Due Diligence, Beneficial Ownership sections)
- FinCEN, Beneficial Ownership Information Reporting Rule (31 CFR §1010.380)
- FinCEN, Customer Due Diligence Rule (31 CFR §1010.230)
- Basel Committee on Banking Supervision, Customer Due Diligence for Banks (2014)
- FATF Recommendation 24 — Transparency and Beneficial Ownership of Legal Persons (March 2022 revision)
- PCAOB AS 2410 — Related Parties
Data architecture reference:
- Inmon, W.H. (2005). Building the Data Warehouse (4th ed.). Wiley.
- Kimball, R., & Ross, M. (2013). The Data Warehouse Toolkit (3rd ed.). Wiley.
- Kleppmann, M. (2017). Designing Data-Intensive Applications. O’Reilly.
- Armbrust, M., Ghodsi, A., Xin, R., & Zaharia, M. (2021). “Lakehouse: A New Generation of Open Platforms That Unify Data Warehousing and Advanced Analytics.” CIDR 2021.
Reproducible artifacts: Companion DD Tech Lab repository at https://github.com/noahrgreen/dd-tech-lab-companion. The the Foundry Ontology Design for Counterparty Risk Investigations article bundle ships at articles/001_foundry_ontology_counterparty_risk/ and contains: the counterparty-risk ontology schema as parseable YAML (ontology_schema/counterparty_risk_ontology.yaml); synthetic worked-example data as CSV (synthetic_data/counterparty.csv, person.csv, ultimate_beneficial_owner.csv, adverse_media_mention.csv, audit_entry.csv); Python dataclass stubs and an end-to-end run script (foundry_sdk_stubs/ontology_classes.py + run_worked_example.py); the Workshop module JSON spec (workshop_module/counterparty_risk_investigation_module.json); and the ElevateRiskRating ActionType template YAML (action_templates/elevate_risk_rating.yaml). All artifacts are verifiable at the live GitHub URL — the YAML parses via yaml.safe_load, the Python runs end-to-end on stdlib only, the CSVs load via pandas.read_csv. They exist at the article’s publication time, not as a future promise.
Current-status caveat: This article cites FinCEN BOI (31 CFR §1010.380), UK PSC (Companies Act 2006), FATF Recommendation 24, SR 11-7, OCC Bulletin 2011-12, SOX §404, PCAOB AS 2410, and the FFIEC BSA/AML Examination Manual as regulatory anchors. The FinCEN BOI rule status in particular has been actively revised through 2024-2025 (Treasury / FinCEN issued an interim final rule in 2025 affecting reporting obligations for U.S. companies and U.S. persons). Practitioners should verify current applicability of any cited regulation before relying on the regulatory framing for an operational implementation. The architectural patterns in this article are durable across regulatory revisions; the specific compliance implications are not.