Beneficial ownership: who actually owns the account
A corporate user is a fiction. Money is owed to humans behind the corporation.
By Solomon Ajayi · Free to read, no signup
A user opens a business account on your platform: 'ACME Logistics Ltd.' From a basic KYC view, the account is opened to a registered company. From an AML view, you need to identify the BENEFICIAL OWNERS, the natural persons who ultimately own >25% (in some jurisdictions: >10%) of ACME. Every regulator now requires beneficial ownership tracking (CBN, EU AMLD 5/6, US FinCEN's CTA). The ledger doesn't change much, the same user-wallet liability exists for ACME's account, but METADATA on every entry needs to surface beneficial-owner information for regulatory queries like 'show all transactions on accounts ultimately controlled by X.' This lesson posts a transaction on ACME's account with beneficial-ownership metadata embedded.
A corporate account holder is a legal fiction. ACME Logistics Ltd does not have intentions or assets of its own; the humans who control it do. Beneficial ownership tracking is how regulators force you to look past the company name to the natural persons who ultimately own more than a threshold stake (often above twenty-five percent, sometimes above ten). The deposit itself is a perfectly ordinary cash-in, Bank Account up, ACME's Wallet up, but the question the regulator asks is not what moved, it is who was really behind it.
The ledger shape does not change to answer that. What changes is the discipline of stamping beneficial-owner context onto every entry as metadata, so a query like show all transactions on accounts ultimately controlled by this person actually has an answer. And the stamp must be a snapshot taken at write time, because ownership changes. If a thirty-percent owner is later added to a sanctions list, you need to know who controlled the account when each historical transaction happened, not who controls it today.
When a beneficial owner is sanctioned, the cascade is unforgiving: any ownership above zero contaminates the whole account, so ACME gets frozen even though ACME itself is not on any list. The freeze entry looks like a SAR freeze, but the reason code (bo_sanctions_cascade) is what lets a later audit prove why a clean company's funds were locked. A PEP owner is gentler, no freeze, just a flag for enhanced due diligence, often recorded as a one-naira marker carrying the reason.
Worked example, step by step
Initial deposit ₦500,000 by ACME, BO metadata captured
ACME Logistics Ltd deposits ₦500,000. Standard cash-in shape. The metadata payload carries the beneficial-owner registry, 3 individuals with their respective ownership percentages.
| Account | Debit | Credit |
|---|---|---|
| Bank Account (1200) | ₦500,000.00 | |
| ACME Logistics Wallet (2000) | ₦500,000.00 |
Bank Account UP ₦500,000 (debit). ACME Logistics Wallet UP ₦500,000 (credit). Two-line entry. The audit-trail metadata holds the BO snapshot AT THE TIME of the entry, important because BO can change and you want to know who controlled the account when each transaction happened.
Sanctioned BO discovered: freeze ACME's account
Three months later, one of ACME's beneficial owners (30% stake) is added to the OFAC list. By LAW, you must treat the entire account as if owned by the sanctioned person (any ownership >0% triggers the cascade). Freeze the wallet, just like a SAR freeze.
| Account | Debit | Credit |
|---|---|---|
| ACME Logistics Wallet (2000) | ₦500,000.00 | |
| Bank Account (1200) | ₦500,000.00 |
ACME Logistics Wallet DOWN ₦500,000 (debit). Generic 'Frozen' liability UP ₦500,000, we reuse the SAR Frozen account from lesson 66 in spirit. The reason metadata is what makes this different: reasonCode='bo_sanctions_cascade' so a future audit can prove WHY ACME got frozen even though ACME itself isn't sanctioned.
Takeaway
Beneficial ownership tracking sits ABOVE the journal entry, it's identity-graph data that gets STAMPED onto every entry as metadata so the regulator's 'show me everything controlled by person X' query has answers. The ledger itself doesn't change shape; what changes is the discipline of carrying BO context on every transaction. Build a BO registry table separate from the user table, with effective-dated rows (BO can change), and resolve the BO snapshot at write-time so historical entries always reflect the BO context AT THAT MOMENT, not today's.
Practice this on a real ledger
Reading is half of it. Open this lesson in the lab to post the entries yourself against a real Postgres-backed double-entry ledger, with the validation on. Free, your sandbox is yours.