Distribute frozen federation corpus by concept destination
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a070b5-4994-7271-bd8b-7c3dbcedec4b
This commit is contained in:
parent
3e3191549a
commit
372f671eef
81 changed files with 14146 additions and 99 deletions
|
|
@ -0,0 +1,183 @@
|
|||
# Beneficial Ownership — CDD, BOI, and KYC Modeling
|
||||
|
||||
## Source Type
|
||||
|
||||
Regulatory framework synthesis. FinCEN CDD Rule (31 CFR 1010.230), Corporate
|
||||
Transparency Act / BOI reporting, FATF Recommendation 24, and KYC industry
|
||||
practice.
|
||||
|
||||
## Domain
|
||||
|
||||
Beneficial ownership identification for legal entity customers — financial
|
||||
institution due diligence, government transparency registries, and regulated
|
||||
commercial onboarding.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
Beneficial ownership is the regulatory answer to "who really controls this
|
||||
legal entity customer?" It is **not** the same as corporate parent ownership
|
||||
(LEI Level 2), operational resource ownership (Cerbos), or CRM account hierarchy.
|
||||
Regulators impose **two independent prongs** (equity and control), trust
|
||||
look-through rules, nominee prohibitions, and evidence retention — all scoped
|
||||
to **counterparty risk**, not general graph semantics.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
### FinCEN CDD Rule (customer due diligence)
|
||||
|
||||
- **Legal entity customer**: corporations, LLCs, general partnerships, and
|
||||
similar entities opening accounts at covered financial institutions.
|
||||
- **Beneficial owner — ownership prong**: each individual who directly or
|
||||
indirectly owns **25% or more** of equity interests.
|
||||
- **Beneficial owner — control prong**: a **single** individual with significant
|
||||
responsibility to control, manage, or direct the legal entity (e.g., CEO,
|
||||
CFO, managing member, general partner, president).
|
||||
- **Collection at account opening**: identify and verify BO identities when a
|
||||
new account opens (with 2026 exceptive relief allowing reuse after first
|
||||
account unless risk triggers update).
|
||||
- **Nominee prohibition**: legal entity must identify **ultimate** beneficial
|
||||
owners, not nominees or straw men.
|
||||
- **Trust look-through**: when a trust owns 25%+ equity, identify natural persons
|
||||
behind the trust (settlor, trustees, beneficiaries as applicable); a legal
|
||||
entity trustee does **not** satisfy the ownership prong — natural persons must
|
||||
be identified.
|
||||
- **Risk-based updates**: ongoing CDD may require BO refresh on triggering
|
||||
events, not only at opening.
|
||||
- **CIP alignment**: BO verification procedures must contain CIP-equivalent
|
||||
elements for individuals but are not identical to the institution's CIP.
|
||||
|
||||
### BOI / Corporate Transparency Act (entity reporting)
|
||||
|
||||
- **Distinct from CDD**: BOI is a **filing obligation on reporting companies**
|
||||
to FinCEN's BOI registry, not a financial-institution collection rule.
|
||||
- **Reporting company beneficial owner**: similar dual-prong concept (substantial
|
||||
ownership + substantial control) with FinCEN ID for individuals.
|
||||
- **US regulatory volatility (2025–2026)**: interim final rules and litigation
|
||||
have substantially narrowed or suspended BOI reporting for many US domestic
|
||||
entities. **CDD beneficial ownership collection by financial institutions
|
||||
remains in force** for covered institutions regardless of BOI reporting shifts.
|
||||
- **Foreign entities**: BOI and transparency expectations remain more relevant
|
||||
for non-US reporting companies and cross-border KYC.
|
||||
|
||||
### FATF Recommendation 24
|
||||
|
||||
- Requires countries to ensure adequate, accurate, and up-to-date **beneficial
|
||||
ownership information** on legal persons, accessible to competent authorities.
|
||||
- Supports **multi-prong** definitions (ownership threshold + control) and
|
||||
look-through for complex structures (trusts, nominees, layered ownership).
|
||||
- Drives national registries and financial-sector CDD alignment globally.
|
||||
|
||||
### KYC practice overlay
|
||||
|
||||
- Institutions may adopt **lower equity thresholds** for high-risk customers
|
||||
(e.g., 10%) under AML program risk policies.
|
||||
- **PEP screening** applies to beneficial owners, not only account signers.
|
||||
- **Sanctions screening** (OFAC) must cover identified beneficial owners.
|
||||
- BO evidence retained for years after relationship ends (BSA record retention).
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| Beneficial owner | Natural person owning 25%+ or exercising substantial control. |
|
||||
| Ownership prong | Equity-interest threshold test. |
|
||||
| Control prong | Significant management/control responsibility test. |
|
||||
| Legal entity customer | Entity opening a financial account subject to CDD. |
|
||||
| CDD Rule | FinCEN customer due diligence requirements (2016, amended). |
|
||||
| BOI / CTA | Corporate Transparency Act beneficial ownership information reporting. |
|
||||
| FinCEN ID | Individual identifier for BOI filers. |
|
||||
| Nominee / straw man | Non-ultimate owner; prohibited as BO response under CDD. |
|
||||
| Look-through | Identifying natural persons behind trusts or intermediary entities. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **Beneficial ownership is relationship semantics**, not a new actor type.
|
||||
The natural person remains **Natural Person**; the assertion is regulatory.
|
||||
- **Ownership prong and control prong are orthogonal** — one person may satisfy
|
||||
both, and multiple persons may satisfy ownership prong while exactly one
|
||||
control-prong person is required under US CDD.
|
||||
- **Beneficial ownership ≠ corporate parent ownership** (LEI Level 2 describes
|
||||
corporate structure; BO describes natural persons behind a customer entity).
|
||||
- **Beneficial ownership ≠ Representation** (authorized signers may represent
|
||||
without being beneficial owners).
|
||||
- **Lifecycle is risk-triggered**, not merely account-open/close.
|
||||
- **Regulatory regime is a scope dimension** — US CDD, EU AMLD, FATF R24, and
|
||||
BOI filing may differ; canon models the relationship, downstream applies law.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
### Resolved: dedicated relationship type
|
||||
|
||||
**Beneficial Ownership Relationship** is a first-class relationship type — **not**
|
||||
an Ownership subtype with `beneficial` metadata.
|
||||
|
||||
**Rationale:**
|
||||
|
||||
| Concern | Why not Ownership subtype |
|
||||
| --- | --- |
|
||||
| Semantic collision | Ownership in canon covers records, tenants, resources, corporate parents — not regulated natural-person BO. |
|
||||
| Dual prongs | Ownership prong (%) and control prong (role) are regulatory-specific; corporate Ownership edges lack this structure. |
|
||||
| Trust look-through | Requires intermediary entity traversal metadata absent from generic Ownership. |
|
||||
| Evidence & scope | BO ties to CDD/AML Evidence Source, Commercial Relationship, and jurisdictional scope — distinct lifecycle from LEI parent edges. |
|
||||
| Projection safety | Prevents Cerbos/Zanzibar "owner" tuples from silently implying KYC beneficial owner compliance. |
|
||||
|
||||
**Beneficial Owner** remains a glossary label for the **natural person** who is
|
||||
the target of a Beneficial Ownership Relationship — not a participation root.
|
||||
|
||||
### Recommended relationship fields
|
||||
|
||||
- `relationship_type`: `beneficial_ownership`
|
||||
- `source`: Natural Person
|
||||
- `target`: Organization / Legal Entity (the legal entity **customer**)
|
||||
- `scope`: jurisdiction + institution/program (e.g., US CDD, EU AMLD)
|
||||
- `ownership_prong`: boolean
|
||||
- `control_prong`: boolean
|
||||
- `equity_percentage`: optional numeric (when ownership prong)
|
||||
- `control_basis`: optional enum (e.g., `ceo`, `managing_member`, `general_partner`)
|
||||
- `intermediary_chain`: optional ordered list for trust/entity look-through
|
||||
- `evidence_reference`: CDD certification, BOI filing, registry extract
|
||||
- `lifecycle_state`: proposed, active, superseded, revoked
|
||||
- `regulatory_basis`: optional reference (CDD Rule, FATF R24, national statute)
|
||||
|
||||
### Mapping table
|
||||
|
||||
| Source concept | Canonical mapping |
|
||||
| --- | --- |
|
||||
| Beneficial owner (person) | Natural Person |
|
||||
| BO linkage | Beneficial Ownership Relationship |
|
||||
| CDD certification | Evidence Source |
|
||||
| Legal entity customer | Organization / Legal Entity + Commercial Relationship |
|
||||
| BOI filing record | Evidence Source (registry) on Legal Entity |
|
||||
| FinCEN ID | Identifier (government registry) on Natural Person |
|
||||
| PEP/sanctions hit on BO | Lifecycle State / Trust Relationship on BO relationship |
|
||||
| LEI Level 2 parent | Ownership Relationship (corporate structure — separate) |
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Beneficial owner (CDD)** vs. **beneficial owner (BOI filing)** vs.
|
||||
**beneficial owner (transparency registry)**: same conceptual person, different
|
||||
regulatory scopes and evidence — use `scope` and `regulatory_basis` metadata.
|
||||
- **Owner (Cerbos resource)** vs. **beneficial owner**: authorization attribute
|
||||
vs. regulated natural-person linkage.
|
||||
- **Shareholder** vs. **beneficial owner**: not all shareholders meet BO thresholds;
|
||||
control prong may identify non-shareholders.
|
||||
|
||||
## Open Questions
|
||||
|
||||
*(none — settled in `commercial-identity-nuance-settlement.md`)*
|
||||
|
||||
## Settled
|
||||
|
||||
- `control_basis` enum — jurisdiction-neutral role codes + `regulatory_basis`.
|
||||
- FinCEN ID → **Registry Identifier** on Natural Person.
|
||||
- Exempt entities → **Beneficial Ownership Exemption** Evidence (not absence).
|
||||
- BOI filing volatility separated from CDD Beneficial Ownership Relationships.
|
||||
|
||||
## References
|
||||
|
||||
- FinCEN, CDD Rule FAQs — https://www.fincen.gov/resources/statutes-and-regulations/cdd-rule-faqs
|
||||
- FinCEN, CDD Final Rule — https://www.fincen.gov/resources/statutes-regulations/cdd-final-rule
|
||||
- FinCEN, Account Opening Exceptive Relief Order (FIN-2026-R001) — https://www.fincen.gov/system/files/2026-02/FinCEN-Order-CCDExceptiveRelief.pdf
|
||||
- FATF, Recommendation 24 — https://www.fatf-gafi.org/en/topics/fatf-recommendations.html
|
||||
- Open Ownership, reliable identifiers for corporate vehicles — https://www.openownership.org/en/publications/using-reliable-identifiers-for-corporate-vehicles-in-beneficial-ownership-data/
|
||||
- Internal: `kyc-aml-commercial-identity-binding.md`, `lei-gleif-legal-entity-identifier.md`
|
||||
|
|
@ -0,0 +1,240 @@
|
|||
# Commercial Identity Nuance Settlement (2026)
|
||||
|
||||
## Source Type
|
||||
|
||||
identity-canon adjudication note — resolves remaining open questions and
|
||||
"remaining nuance" items across the commercial-identity research stack.
|
||||
|
||||
## Domain
|
||||
|
||||
Standard enums, cross-registry linking rules, regulatory layering, and adapter
|
||||
guidance for commercial identity edge cases.
|
||||
|
||||
## Beneficial Ownership Nuances
|
||||
|
||||
### `control_basis` enum (settled)
|
||||
|
||||
Use a **jurisdiction-neutral role code** on Beneficial Ownership Relationship,
|
||||
plus `regulatory_basis` for program-specific rules.
|
||||
|
||||
| `control_basis` | Typical sources |
|
||||
| --- | --- |
|
||||
| `senior_managing_official` | FATF generic; US CDD control prong when no other role fits |
|
||||
| `chief_executive` | CEO, managing director, president, executive director |
|
||||
| `chief_financial` | CFO, treasurer with control |
|
||||
| `managing_member` | LLC managing member |
|
||||
| `general_partner` | Partnership general partner |
|
||||
| `board_chair` | Chair with operational control |
|
||||
| `trustee` | Trust with management control |
|
||||
| `settlor_with_control` | Settlor retaining control over trust |
|
||||
| `other_control` | Catch-all — require `control_basis_detail` free text |
|
||||
|
||||
`regulatory_basis` values: `us_cdd`, `us_boi_cta`, `eu_amld`, `fatf_r24`, `national_statute`.
|
||||
|
||||
US CDD "significant responsibility to control, manage, or direct" maps to the
|
||||
most specific code available, else `senior_managing_official`. EU AMLD "senior
|
||||
managing official" maps directly. Store **one** control-prong person per US CDD
|
||||
rule; multiple ownership-prong persons allowed.
|
||||
|
||||
### FinCEN ID (settled)
|
||||
|
||||
FinCEN ID for BOI filers maps to **Registry Identifier**:
|
||||
|
||||
- `authority_class: government_registry`
|
||||
- `scheme: fincen_individual_id` (or jurisdiction-specific extension)
|
||||
- `jurisdiction: US`
|
||||
- Attached to **Natural Person**, not Organization.
|
||||
|
||||
### Exempt legal entity customers (settled)
|
||||
|
||||
Do not rely on absence of Beneficial Ownership Relationships. Record explicit
|
||||
**Beneficial Ownership Exemption** as **Evidence Source** on the Legal Entity /
|
||||
Organization with:
|
||||
|
||||
- `exemption_type`: `publicly_traded`, `government_entity`, `regulated_financial_institution`, `subsidiary_of_exempt_parent`, `other`
|
||||
- `regulatory_basis`, `evidence_reference`, `lifecycle_state`
|
||||
|
||||
Absence alone is ambiguous (not collected vs. exempt vs. not applicable).
|
||||
|
||||
### BOI filing volatility vs. CDD (settled)
|
||||
|
||||
Separate regulatory layers in canon — do not merge:
|
||||
|
||||
| Layer | Canon artifact | Volatility |
|
||||
| --- | --- | --- |
|
||||
| CDD beneficial ownership | Beneficial Ownership Relationship | Stable for covered FIs; collection obligation endures |
|
||||
| BOI registry filing | Evidence Source (`evidence_type: boi_filing`) | Jurisdiction-dependent; track lifecycle downstream |
|
||||
| Transparency registry | Evidence Source (`evidence_type: bo_registry_extract`) | Per national register |
|
||||
|
||||
Canon does not prescribe legal outcomes; downstream adapters apply current statute.
|
||||
CDD relationships remain even when BOI filing requirements change.
|
||||
|
||||
## Registry Identifier Nuances
|
||||
|
||||
### `authority_class` extension (settled)
|
||||
|
||||
Add `industry_association` for identifiers issued by trade, standards, or
|
||||
procurement bodies without government incorporation authority:
|
||||
|
||||
- NCAGE / CAGE (defense supplier ID)
|
||||
- GS1 GLN when used as organization/location key in supply chain
|
||||
|
||||
Retain `government_registry`, `regulatory_global`, `commercial_proxy`, `tax`.
|
||||
|
||||
### Cross-registry Synonymity strength (settled)
|
||||
|
||||
| Link | Default strength | Notes |
|
||||
| --- | --- | --- |
|
||||
| LEI ↔ national company reg / ALEI | **strong** | Same legal entity when LOU or government register confirms |
|
||||
| LEI ↔ UEI | **strong** | When SAM.gov or authoritative crosswalk confirms |
|
||||
| LEI ↔ DUNS | **medium** | D&B may assign per location; proxy authority |
|
||||
| DUNS ↔ UEI | **medium** | Historical procurement migration |
|
||||
| DUNS ↔ company reg | **medium** | Branch/location mismatch common |
|
||||
| company reg ↔ ALEI | **authoritative** | Same register encoding |
|
||||
|
||||
Use `relation_type: same_as` when strength is strong or authoritative;
|
||||
`linked_to` for medium. Require `evidence_reference` (crosswalk, operator verify).
|
||||
|
||||
### ISO 6523 OPI / branch modeling (settled)
|
||||
|
||||
ISO 6523 **organization part identifier (OPI)** models a **branch or org unit**,
|
||||
not a separate legal entity by default:
|
||||
|
||||
- Store OPI on **Registry Identifier** as optional `organization_part_id`.
|
||||
- Map branch to **Organization Unit** (Group specialization) or child **Organization**
|
||||
when operationally distinct.
|
||||
- Branch DUNS + parent LEI: link branch Proxy Commercial Identifier to parent
|
||||
Organization via structural relationship; Synonymity Assertion (medium) between
|
||||
branch DUNS and parent LEI when same legal entity confirmed.
|
||||
|
||||
## Reputation and Assurance Nuances
|
||||
|
||||
### `assurance_tier` vs. numeric score (settled)
|
||||
|
||||
**Primary:** `assurance_tier` enum (`opinion` | `observed` | `committed` | `adjudicated`).
|
||||
|
||||
**Optional:** `numeric_score` + `score_scale` on Evidence Source for downstream
|
||||
(e.g., PAYDEX 0–100, star rating 1–5). Downstream maps score ranges to tiers;
|
||||
canon does not merge tiers from scores alone.
|
||||
|
||||
### Platform escrow without separate contract (settled)
|
||||
|
||||
Segregated escrow with defined release conditions is **committed** tier:
|
||||
|
||||
- Model **Commercial Commitment** `commitment_type: escrow`
|
||||
- Evidence Source: platform escrow terms, payment-provider escrow object, or
|
||||
marketplace buyer-protection policy accepted at transaction time
|
||||
- Funds segregation + conditional release = commitment, not merely observed metric
|
||||
|
||||
### Cross-platform reputation portability (settled)
|
||||
|
||||
Portable reputation uses **Synonymity Assertion** between **Reputation Signal**
|
||||
Evidence Sources:
|
||||
|
||||
- Default `relation_type: linked_to` (not `same_as`)
|
||||
- Default strength: **weak**
|
||||
- Upgrade to medium only with verified identity bridge (same Natural Person proof,
|
||||
verified purchase on both platforms, operator confirmation)
|
||||
- Require `portability_evidence` reference; scope must list both platforms
|
||||
|
||||
### Smart-contract / oracle outcomes (settled)
|
||||
|
||||
| Outcome type | Tier | Canon |
|
||||
| --- | --- | --- |
|
||||
| On-chain condition check (oracle, escrow release) | observed | Performance Evidence |
|
||||
| Binding ADR with identified parties (incl. on-chain tribunal with published rules) | adjudicated | Adjudication Outcome |
|
||||
| Court judgment enforced on-chain | adjudicated | Adjudication Outcome |
|
||||
|
||||
Automation alone does not elevate to adjudicated without identifiable dispute
|
||||
authority and parties.
|
||||
|
||||
## Payment Nuances
|
||||
|
||||
### Network tokens e.g. Visa VTS (settled)
|
||||
|
||||
Network tokens map to **Payment Instrument Reference**:
|
||||
|
||||
- `instrument_type: network_token`
|
||||
- `network_token_service` (e.g., `visa_vts`, `mastercard_mdes`)
|
||||
- Same lifecycle and PCI boundary as `pm_xxx` references
|
||||
|
||||
### Shared payment methods across org customers (settled)
|
||||
|
||||
One Payment Instrument Reference may attach to **multiple Commercial Records**
|
||||
within the same payment-provider org **Scope**:
|
||||
|
||||
- `sharing_scope: payment_provider_org`
|
||||
- `shared_across_records: [commercial_record_ids]`
|
||||
- Do not Synonymity-merge Commercial Records — only share the instrument reference
|
||||
|
||||
### Customer wallet balance (settled)
|
||||
|
||||
Provider ledger balance (Stripe Customer balance) is a **Commercial Record**
|
||||
attribute `provider_ledger_balance` — not a Credential, not a Commercial Commitment.
|
||||
Currency and provider scope required.
|
||||
|
||||
## CRM and Pipeline Nuances
|
||||
|
||||
### `binding_trigger` enum (settled)
|
||||
|
||||
| Value | Commitment state | Typical evidence |
|
||||
| --- | --- | --- |
|
||||
| `quote_accepted` | proposed | CPQ acceptance, e-sign |
|
||||
| `loi_signed` | proposed | Signed LOI |
|
||||
| `purchase_order_executed` | active | PO record |
|
||||
| `contract_executed` | active | Signed agreement |
|
||||
| `subscription_activated` | active | Billing webhook |
|
||||
| `regulatory_onboarding_complete` | active | KYC/KYB completion |
|
||||
| `org_policy_closed_won` | active only if org maps Closed Won → executed contract **and** policy documented as Evidence |
|
||||
|
||||
`org_policy_closed_won` is downstream-configured; canon requires explicit Evidence.
|
||||
|
||||
### Renewal Opportunity (settled)
|
||||
|
||||
| Situation | Canon treatment |
|
||||
| --- | --- |
|
||||
| Renewal on existing contract (same agreement extended) | **Commitment amendment** Evidence on existing Commercial Commitment; optional Pipeline Pursuit for forecast tracking |
|
||||
| Competitive rebid / new agreement cycle | New **Pipeline Pursuit** |
|
||||
| Material term change | Commitment amendment + may create Pipeline Pursuit |
|
||||
|
||||
Rule: if `amends_commitment_id` is set and change type is `renewal` or `amendment`,
|
||||
do not create a new root Commercial Commitment unless terms are net-new contract.
|
||||
|
||||
### Partner vs. customer Opportunity (settled)
|
||||
|
||||
Same **Pipeline Pursuit** type with `pursuit_role`:
|
||||
|
||||
- `customer` (default)
|
||||
- `partner` (channel, alliance)
|
||||
- `vendor` (reverse sourcing)
|
||||
|
||||
Role affects **Commercial Relationship** typing, not Pipeline Pursuit structure.
|
||||
|
||||
### Person Account adapter guidance (settled)
|
||||
|
||||
Salesforce Person Account and similar B2C shortcuts:
|
||||
|
||||
- **Canon storage:** Natural Person + Commercial Record (split layers)
|
||||
- **Adapter projection:** `projection_mode: person_account_combined` on export only
|
||||
- Do not introduce Person Account as canonical root; discourage unified tables in
|
||||
downstream schema without layer tags
|
||||
|
||||
## eIDAS / EUDI Nuances (commercial stack)
|
||||
|
||||
### Qualified electronic seal (settled)
|
||||
|
||||
Maps to **Credential** with `credential_type: qualified_seal`, bound to
|
||||
**Organization** / **Legal Entity** through **Representation Relationship**
|
||||
(signing officer or mandated agent). Distinct from login Credential.
|
||||
|
||||
### EUDI organizational wallet Scope (settled)
|
||||
|
||||
Organizational wallet is a **Scope** specialization (`wallet_scope`) holding
|
||||
wallet-hosted **Credentials** and **Claims** — not a **Tenant** (no admin
|
||||
isolation semantics). Link wallet Scope to **Commercial Record** and Organization
|
||||
actor via Commercial Relationship.
|
||||
|
||||
## References
|
||||
|
||||
All prior commercial-identity source notes. This note supersedes their Open
|
||||
Questions sections where marked settled below.
|
||||
|
|
@ -0,0 +1,153 @@
|
|||
# Commercial Identity Synthesis
|
||||
|
||||
## Source Type
|
||||
|
||||
identity-canon research synthesis connecting commercial theory, law, regulation,
|
||||
and software practice to the canonical model.
|
||||
|
||||
## Domain
|
||||
|
||||
Cross-cutting commercial identity — binding, trust, persistence, and layer separation.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
This note captures the research prompt: **identity and commerce are tightly coupled
|
||||
in practice**. Conceptual or login-only identity can remain fluid when no commercial
|
||||
value or enforceable promises attach. **Commercial binding** increases an identity's
|
||||
relevance to other actors and creates foundations for trust, shared information, and
|
||||
durable relationships.
|
||||
|
||||
## The Binding Gradient
|
||||
|
||||
| Stage | Commercial stake | Identity behavior | Canon pattern |
|
||||
| --- | --- | --- | --- |
|
||||
| Anonymous browse | None | Fluid, discardable | Persona, ephemeral Identifier |
|
||||
| Free trial / lead | Low | Pseudonymous, reversible | Account + weak Commercial Record |
|
||||
| Paying subscriber | Medium | Stable tenant + billing ID | Organization + Tenant + Commercial Record |
|
||||
| KYC/AML customer | High | Verified, monitored, retained | Commercial Record + Evidence + BO linkage |
|
||||
| Regulated markets (LEI) | Very high | Renewed legal identity, ownership public | Legal Entity + LEI Identifier + Lifecycle |
|
||||
| Contractual enterprise | High | Agency, seals, signatures | Commercial Commitment + Representation |
|
||||
|
||||
**Insight:** fluidity is not a bug — it is rational when commercial externalities are
|
||||
absent. Binding is what makes identity **economically and legally salient**.
|
||||
|
||||
## Layer Model (Commercial + Identity)
|
||||
|
||||
```text
|
||||
Actor Layer Natural Person, Organization, Legal Entity
|
||||
Record Layer Account (access), Commercial Record (billing/CRM/regulatory)
|
||||
Reference Layer Identifiers (LEI, DUNS, UEI, VAT, stripe_customer_id)
|
||||
Relationship Layer Commercial Relationship, Representation, Ownership, Trust
|
||||
Commitment Layer Commercial Commitment (contract, subscription, payment mandate)
|
||||
Evidence Layer KYC files, credit history, registry extracts, qualified credentials
|
||||
Projection Layer Auth Subject, Auth Principal (unchanged — not commercial roots)
|
||||
```
|
||||
|
||||
Commerce does not replace identity layers; it **selectively hardens** them when
|
||||
counterparties must rely, sue, invoice, or report.
|
||||
|
||||
## How Binding Creates Trust
|
||||
|
||||
From commercial theory and practice:
|
||||
|
||||
1. **Attribution**: counterparties know **who** bears liability (legal person, BO, agent).
|
||||
2. **Commitment**: contracts, subscriptions, and payment authorizations create **costly exit**.
|
||||
3. **Evidence**: KYC, LEI, registry credentials, and credit files provide **verifiable history**.
|
||||
4. **Reputation / assurance**: tiered reliance from opinion signals (reviews) through
|
||||
observed metrics (PAYDEX) to committed stakes (bonds) and adjudicated outcomes
|
||||
(courts) — see **Counterparty Assurance Gradient**.
|
||||
5. **Enforcement**: law of agency and contract makes promises **actionable** beyond platform ToS.
|
||||
|
||||
Trust Relationship in canon should often be **justified by** Commercial Relationship +
|
||||
Commercial Commitment + Evidence, not declared ad hoc.
|
||||
|
||||
## Software Mirrors (Practical)
|
||||
|
||||
| System | Commercial artifact | Identity separation lesson |
|
||||
| --- | --- | --- |
|
||||
| Stripe | Customer | Billing ≠ login |
|
||||
| Salesforce | Account / Contact | CRM ≠ User |
|
||||
| Auth0/Stytch | Organization / Member | Subscriber ≠ billing record |
|
||||
| KYC platforms | Customer profile + BO | Regulated counterparty ≠ session |
|
||||
| GLEIF | LEI | Legal entity ID for markets |
|
||||
| D&B | DUNS + PAYDEX | Credit identity + reputation |
|
||||
| eIDAS/EUDI | Legal person wallet | Qualified org credentials |
|
||||
|
||||
## Canon Decisions From This Research
|
||||
|
||||
### Rejected
|
||||
|
||||
- **Customer Account** as canonical type (overloads layers).
|
||||
|
||||
### Added / strengthened
|
||||
|
||||
- **Commercial Record** — billing, CRM, regulatory counterparty records.
|
||||
- **Commercial Relationship** — vendor/customer commercial link.
|
||||
- **Commercial Commitment** — enforceable or costly promise binding parties (contract,
|
||||
subscription, payment mandate, regulatory onboarding acceptance).
|
||||
- **Beneficial Ownership Relationship** — dedicated type from Natural Person to
|
||||
Organization/Legal Entity for KYC/CDD (not Ownership subtype).
|
||||
- **Registry Identifier** and **Proxy Commercial Identifier** — Reference layer
|
||||
subtypes with authority class, ICD scheme, and renewal lifecycle.
|
||||
- **Counterparty Assurance Gradient** — opinion → observed → committed →
|
||||
adjudicated; Reputation Signal, Performance Evidence, Adjudication Outcome.
|
||||
- **Payment Instrument Reference** + **Payment Mandate** — PCI boundary; not Credential.
|
||||
- **Pipeline Pursuit** — CRM Opportunity before Commercial Commitment promotion.
|
||||
|
||||
### Unchanged roots
|
||||
|
||||
- **Actor** remains participation root.
|
||||
- **Account** remains operational access record.
|
||||
- Login, authz, and social layers unchanged; commerce **binds** them when stakes require.
|
||||
|
||||
## Fluid ↔ Bound Transitions
|
||||
|
||||
Model as lifecycle events, not silent merges:
|
||||
|
||||
- Lead → Account (CRM conversion): weak → medium evidence.
|
||||
- Opportunity opened: Pipeline Pursuit — not Commercial Commitment until binding trigger.
|
||||
- Trial → paid subscription: Commercial Commitment (subscription) + Payment Mandate
|
||||
+ Payment Instrument Reference.
|
||||
- Org onboarding → KYC complete: raise Assurance Level, add BO relationships.
|
||||
- Pseudonym → verified legal person: Synonymity Assertion with strength upgrade and scope change.
|
||||
|
||||
## Scenario Impact
|
||||
|
||||
- **S04 (vendor/customer tenants)**: add Commercial Record per customer tenant, Commercial
|
||||
Commitment for subscription/contract.
|
||||
- **S14 (pseudonymous profile)**: incompatible with active Commercial Commitment unless
|
||||
explicitly scoped (e.g., marketplace escrow with privacy partition).
|
||||
- **S15 (legal entity + tenants)**: LEI/registry Identifier + Commercial Record + renewals.
|
||||
|
||||
## Research Gaps
|
||||
|
||||
- Smart contracts and automated Commercial Commitment lifecycle (implementation patterns).
|
||||
- National statute variants beyond settled enum baselines (downstream legal config).
|
||||
|
||||
## Nuance settlement
|
||||
|
||||
Commercial identity edge-case enums and linking rules are consolidated in
|
||||
`commercial-identity-nuance-settlement.md` (2026).
|
||||
|
||||
## Source Notes in This Stack
|
||||
|
||||
- `commercial-trust-binding-theory.md`
|
||||
- `legal-person-agency-contract.md`
|
||||
- `lei-gleif-legal-entity-identifier.md`
|
||||
- `duns-commercial-credit-identity.md`
|
||||
- `kyc-aml-commercial-identity-binding.md`
|
||||
- `eidas-eudi-legal-person-wallet.md`
|
||||
- `salesforce-crm-commercial-record.md`
|
||||
- `beneficial-ownership-kyc-boi.md`
|
||||
- `registry-identifier-subtypes.md`
|
||||
- `reputation-assurance-gradient.md`
|
||||
- `payment-credential-pci-boundary.md`
|
||||
- `crm-pipeline-commitment-threshold.md`
|
||||
- `commercial-identity-nuance-settlement.md`
|
||||
- `../commercial-subscription/b2b-saas-subscriber-tenancy.md`
|
||||
- `../commercial-subscription/stripe-customer-billing.md`
|
||||
|
||||
## References
|
||||
|
||||
See individual source notes. Primary external anchors: GLEIF/ISO 17442, FinCEN CIP,
|
||||
EU eIDAS, D&B DUNS, Salesforce Account model, Auth0/Stytch org tenancy, FATF digital identity.
|
||||
|
|
@ -0,0 +1,119 @@
|
|||
# Commercial Trust and Identity Binding Theory
|
||||
|
||||
## Source Type
|
||||
|
||||
Academic and industry synthesis. Transaction-cost economics, contract performance
|
||||
literature, digital trust research, and identity-canon conceptual framing.
|
||||
|
||||
## Domain
|
||||
|
||||
Commercial theory, trust formation, identity persistence, and the economic
|
||||
function of binding commitments.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
Practitioners often treat login identity and billing identity as separate
|
||||
accidents of software architecture. Commercial theory suggests a deeper
|
||||
pattern: **commercially unbound identities stay fluid**; **commercially bound
|
||||
identities become durable points of coordination** for trust, information
|
||||
sharing, and enforceable promises.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Fluid identity**: participation with low exit cost and weak external reliance;
|
||||
pseudonymous handles, trial accounts, anonymous browsing.
|
||||
- **Commercial binding**: attachment of economic or legal obligation to an
|
||||
identity representation (payment authorization, contract, subscription, KYC
|
||||
onboarding, credit exposure).
|
||||
- **Reputation capital**: value accumulated when past performance is observable
|
||||
and attributable to a stable identity.
|
||||
- **Transaction costs**: search, bargaining, monitoring, and enforcement costs
|
||||
that trust mechanisms reduce (Williamson, Coase tradition).
|
||||
- **Contract performance assurance**: market and legal mechanisms ensuring
|
||||
parties keep promises (bonding, hostages, repeat play, legal enforcement).
|
||||
- **Transient trust**: short-lived trust between previously unknown parties
|
||||
enabled by verified credentials and real-time assurance (EU digital wallet
|
||||
discourse).
|
||||
- **Perpetual master data**: continuous re-validation of enterprise identity
|
||||
attributes once commercial relationships depend on accuracy (KYC/KYB, LEI
|
||||
renewal).
|
||||
- **Counterparty risk**: commercial exposure to wrong or misidentified party;
|
||||
drives identity rigor.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| Binding | Attachment of enforceable or costly-to-break obligation. |
|
||||
| Commitment | Promise backed by legal, financial, or reputational stake. |
|
||||
| Trust | Willingness to rely on another party under uncertainty. |
|
||||
| Reputation | Observable history attributed to an identity. |
|
||||
| Fluid identity | Low-stakes, easily abandoned or rotated representation. |
|
||||
| Bound identity | Identity whose change imposes cost on self or counterparties. |
|
||||
| Assurance | Mechanism increasing confidence in performance or identity. |
|
||||
| Counterparty | Other party in a commercial transaction. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- Identity relevance scales with **stakes of reliance** by other parties.
|
||||
- Without commercial binding, actors optimize for **low friction and privacy**
|
||||
(fluid personas, ephemeral identifiers).
|
||||
- Commercial activity introduces **attribution requirements** (who invoiced,
|
||||
who signed, who is liable).
|
||||
- Trust between commercial actors rests on **identity stability + evidence +
|
||||
enforceable commitments**, not on profile richness alone.
|
||||
- Digital systems separate layers (login, CRM, billing, KYC) but commercial
|
||||
reality treats them as **one counterparty** when risk is integrated.
|
||||
- Reputation and legal liability create **path dependence**: past bindings make
|
||||
future identity changes costly (account migration, LEI renewal, contract novation).
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
- Distinguish **fluid participation** (Actor/Persona/Account with no commercial
|
||||
commitment) from **commercially bound participation** (Commercial Record +
|
||||
Commercial Relationship + Commercial Commitment).
|
||||
- **Trust Relationship** in canon should often be **downstream of** Commercial
|
||||
Relationship and evidenced commitments, not a substitute for them.
|
||||
- **Synonymity Assertion** strength should rise when commercial counterparty
|
||||
risk requires deterministic matching (KYC, LEI, registry ID).
|
||||
- **Lifecycle State** on commercial artifacts gates access and trust (subscription
|
||||
active, delinquent, KYC expired, LEI lapsed).
|
||||
- User insight formalized: conceptual identity without commercial binding may
|
||||
remain intentionally fluid; binding increases **relevance to other commercial
|
||||
actors** and justifies **stronger identifiers and promises**.
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Trust (social)** vs. **trust (commercial)**: following ≠ credit trust.
|
||||
- **Identity (conceptual)** vs. **identity (counterparty)**: philosophy vs. KYC record.
|
||||
- **Binding (technical)** vs. **binding (legal)**: OIDC binding ≠ contract.
|
||||
- **Reputation (brand)** vs. **reputation (performance history)**: marketing vs. credit.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| Theory concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| Fluid identity | Persona / Scoped Identifier without Commercial Commitment |
|
||||
| Commercial binding | Commercial Commitment on Commercial Relationship |
|
||||
| Reputation capital | Performance Evidence history + Trust Relationship (assurance_basis) |
|
||||
| Star ratings / reviews | Reputation Signal (opinion tier) |
|
||||
| Counterparty identification | Commercial Record + Legal Entity + Identifiers |
|
||||
| Contractual promise | Commercial Commitment (contract subtype) |
|
||||
| Assurance mechanism | Assurance Level + Evidence Source |
|
||||
| Transient trust | Trust Relationship with short lifecycle + VC/qualified ID |
|
||||
| Perpetual MDM | Ongoing Evidence Source refresh on Commercial Record |
|
||||
|
||||
## Open Questions
|
||||
|
||||
- Should Commercial Commitment be a Relationship subclass or metadata on
|
||||
Commercial Relationship?
|
||||
- How should fluid-to-bound transitions be modeled (trial → paid, anonymous → KYC)?
|
||||
- Resolved: tiered Evidence Source pattern — see `reputation-assurance-gradient.md`.
|
||||
|
||||
## References
|
||||
|
||||
- Klein and Leffler (1981), role of market forces in contractual performance
|
||||
- Williamson, transaction cost economics (institutional trust)
|
||||
- FATF Guidance on Digital Identity (trust frameworks for financial identity)
|
||||
- Spherity/EUDI organizational wallet discourse on transient trust and perpetual MDM
|
||||
- identity-canon ResearchSeed (trust, synonymity, evidence)
|
||||
|
|
@ -0,0 +1,157 @@
|
|||
# CRM Pipeline and Commercial Commitment Threshold
|
||||
|
||||
## Source Type
|
||||
|
||||
Product data model and sales-operations synthesis. Salesforce Opportunity stages,
|
||||
forecast categories, and contract-law binding thresholds.
|
||||
|
||||
## Domain
|
||||
|
||||
When CRM pipeline artifacts (Opportunity, deal stage, forecast) constitute
|
||||
canonical **Commercial Commitment** vs. provisional pursuit evidence only.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
Salesforce **Opportunity** tracks potential revenue — but most pipeline stages are
|
||||
**forecasts**, not enforceable obligations. Treating every Opportunity as
|
||||
Commercial Commitment would:
|
||||
|
||||
- falsely elevate identity binding during early prospecting;
|
||||
- collide with **Counterparty Assurance Gradient** (pipeline ≠ committed tier);
|
||||
- ignore that **Closed Won** often precedes executed contract in real orgs.
|
||||
|
||||
Canon needs a **promotion threshold** — when pipeline becomes commitment.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
### Salesforce Opportunity model
|
||||
|
||||
- **Opportunity**: deal record tied to Account; amount, stage, close date, forecast.
|
||||
- **Stage**: position in sales process (e.g., Prospecting → Proposal → Negotiation
|
||||
→ Closed Won / Closed Lost).
|
||||
- **Forecast category**: Pipeline, Best Case, Commit, Closed — revenue prediction
|
||||
semantics, not legal commitment.
|
||||
- **Closed Won**: deal marked won in CRM — operational signal; may or may not
|
||||
coincide with signed contract depending on org process.
|
||||
- **Closed Lost**: pursuit ended — no commitment.
|
||||
- **Quote / Order** (CPQ): closer to binding when customer accepts quote or order
|
||||
is placed — stronger evidence than early stage.
|
||||
|
||||
### Binding threshold (legal/commercial)
|
||||
|
||||
A **Commercial Commitment** requires evidenced obligation that raises counterparty
|
||||
reliance — aligned with canon definition and tier 3 assurance:
|
||||
|
||||
| Signal | Binding strength | Canon treatment |
|
||||
| --- | --- | --- |
|
||||
| Lead created | None | Pipeline Pursuit or weak Commercial Record |
|
||||
| Opportunity Prospecting | None | Pipeline Pursuit |
|
||||
| Opportunity Proposal | Low | Pipeline Pursuit + stage Evidence |
|
||||
| Signed quote / LOI | Medium | Commercial Commitment `proposed` |
|
||||
| Executed PO / order | High | Commercial Commitment `active` |
|
||||
| Closed Won (CRM only) | Org-dependent | `proposed` until contract Evidence |
|
||||
| Signed MSA / SOW | High | Commercial Commitment `active` |
|
||||
| Active subscription (Stripe) | High | Commercial Commitment `active` (billing) |
|
||||
|
||||
**Rule:** CRM stage alone is **never sufficient** for `active` Commercial Commitment
|
||||
unless org policy equates Closed Won with executed agreement **and** that policy
|
||||
is recorded as Evidence Source (downstream configuration).
|
||||
|
||||
### Fluid-to-bound transition
|
||||
|
||||
Lead → Account conversion raises commercial attribution (Organization +
|
||||
Commercial Record). Opportunity creation adds **Pipeline Pursuit**. Commitment
|
||||
materializes only at binding trigger — not at Opportunity create.
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **Pipeline is prospective** — counterparties may rely for forecasting internally
|
||||
but external legal reliance is limited until commitment artifacts exist.
|
||||
- **Multiple Opportunities** per Account are normal; commitments may coexist.
|
||||
- **Opportunity amount** is expected value, not obligation amount until contracted.
|
||||
- **Forecast Commit category** (Salesforce) is sales-team confidence, not legal
|
||||
commitment — do not map to Commercial Commitment `active`.
|
||||
- **CPQ Quote accepted** or **e-signature completed** are valid binding triggers
|
||||
with Evidence Source.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
### Resolved: Opportunity is not Commercial Commitment by default
|
||||
|
||||
Map Salesforce **Opportunity** (and HubSpot deal, etc.) to **Pipeline Pursuit** —
|
||||
Record layer artifact for in-flight commercial deal pursuit.
|
||||
|
||||
**Pipeline Pursuit** fields:
|
||||
|
||||
- `source_system` — Salesforce, HubSpot, etc.
|
||||
- `stage` — vendor stage name (Prospecting, Negotiation, Closed Won, …)
|
||||
- `forecast_category` — pipeline, best_case, commit, closed
|
||||
- `expected_amount`, `expected_close_date`
|
||||
- `linked_commercial_record` — CRM Account / Commercial Record
|
||||
- `lifecycle_state` — open, won, lost, abandoned
|
||||
- `binding_status` — `none` | `proposed` | `active` (derived from evidence, not stage alone)
|
||||
|
||||
### Promotion to Commercial Commitment
|
||||
|
||||
Create or activate **Commercial Commitment** only when `binding_trigger` satisfied:
|
||||
|
||||
| Trigger | Commitment state | Evidence |
|
||||
| --- | --- | --- |
|
||||
| Signed LOI / quote acceptance | `proposed` | Document, e-sign event |
|
||||
| Executed PO / order | `active` | Order record |
|
||||
| Closed Won + contract on file | `active` | Contract Evidence Source |
|
||||
| Subscription checkout complete | `active` | Stripe webhook (billing) |
|
||||
| Stage-only Closed Won | **No auto-promotion** | Pipeline Pursuit `won` only |
|
||||
|
||||
**Pipeline Pursuit** may **reference** a Commercial Commitment once promoted;
|
||||
do not replace Opportunity with commitment in CRM adapters — mirror both.
|
||||
|
||||
### What Opportunity stage provides
|
||||
|
||||
Stage changes produce **Evidence Source** events on Pipeline Pursuit (observed
|
||||
tier — internal sales telemetry). They support **Trust Relationship** only for
|
||||
**internal** vendor forecasting, not external counterparty assurance at tier 3.
|
||||
|
||||
### Lead and Account (unchanged)
|
||||
|
||||
- **Lead** → provisional prospect (weak Commercial Record or Pipeline Pursuit seed).
|
||||
- **Account** → **Commercial Record** + Organization.
|
||||
- **Opportunity** → **Pipeline Pursuit** (not Commercial Commitment).
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Opportunity (CRM)** vs. **Commercial Commitment**: forecast vs. obligation.
|
||||
- **Forecast Commit (Salesforce)** vs. **Commercial Commitment (canon)**: homonym disaster.
|
||||
- **Closed Won** vs. **contract signed**: CRM ops vs. legal binding.
|
||||
- **Deal (informal)** vs. **Pipeline Pursuit**: resolve to Pipeline Pursuit.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| CRM concept | Canonical mapping |
|
||||
| --- | --- |
|
||||
| Account | Commercial Record + Organization |
|
||||
| Contact | Natural Person |
|
||||
| Lead | Pipeline Pursuit (seed) / weak Commercial Record |
|
||||
| Opportunity | Pipeline Pursuit |
|
||||
| Stage change | Evidence Source on Pipeline Pursuit |
|
||||
| Quote accepted | Commercial Commitment `proposed` |
|
||||
| Order / contract executed | Commercial Commitment `active` |
|
||||
| Closed Lost | Pipeline Pursuit lifecycle `lost` |
|
||||
| Forecast category "Commit" | Pipeline Pursuit metadata only |
|
||||
|
||||
## Open Questions
|
||||
|
||||
*(none — settled in `commercial-identity-nuance-settlement.md`)*
|
||||
|
||||
## Settled
|
||||
|
||||
- `binding_trigger` enum — seven values including `org_policy_closed_won`.
|
||||
- Renewal on same contract → commitment amendment; rebid → new Pipeline Pursuit.
|
||||
- `pursuit_role`: customer | partner | vendor on Pipeline Pursuit.
|
||||
|
||||
## References
|
||||
|
||||
- Salesforce Opportunity object — https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_opportunity.htm
|
||||
- Shellblack, Salesforce data model overview — https://www.shellblack.com/whiteboard/overview-of-leads-account-and-contacts-the-salesforce-data-model/
|
||||
- Internal: `salesforce-crm-commercial-record.md`, `commercial-identity-synthesis.md`,
|
||||
`reputation-assurance-gradient.md`, `legal-person-agency-contract.md`
|
||||
|
|
@ -0,0 +1,91 @@
|
|||
# DUNS and Commercial Credit Identity
|
||||
|
||||
## Source Type
|
||||
|
||||
Industry registry. Dun & Bradstreet Data Universal Numbering System (D-U-N-S).
|
||||
|
||||
## Domain
|
||||
|
||||
Commercial credit, vendor onboarding, procurement identity, and business verification.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
DUNS predates LEI as a global commercial identifier for **business entities** in
|
||||
trade and credit. It ties identity to **creditworthiness and payment behavior**
|
||||
(PAYDEX), illustrating how commercial activity creates durable, high-stakes identity
|
||||
interest among counterparties.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **DUNS number**: nine-digit proprietary identifier for a business location/entity.
|
||||
- **D&B database**: 300M+ business records; global trade and procurement usage.
|
||||
- **Business entity**: company or location receiving DUNS; not a natural person.
|
||||
- **PAYDEX score**: D&B payment performance score (credit behavior).
|
||||
- **Credit file**: aggregated commercial history attributed to DUNS.
|
||||
- **Government procurement**: historically required DUNS (US); migrated to SAM UEI.
|
||||
- **UEI (Unique Entity Identifier)**: US federal successor identifier in SAM.gov.
|
||||
- **ISO/IEC 6523 ICD 0060**: standard representation for DUNS in ISO identifiers.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| DUNS / D-U-N-S | D&B business identifier. |
|
||||
| Business entity | Company or site in D&B registry. |
|
||||
| PAYDEX | Payment performance score. |
|
||||
| Credit file | Commercial history record. |
|
||||
| UEI | US government unique entity ID (SAM.gov). |
|
||||
| Vendor onboarding | Procurement verification using DUNS/UEI. |
|
||||
| Headquarters vs. branch | Separate DUNS per distinct business location. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **Commercial identity serves credit and procurement**, not authentication.
|
||||
- **Payment history feeds reputation** attributable to identifier.
|
||||
- **Multiple national ID schemes** (DUNS, UEI, LEI, VAT, company reg) coexist; linking
|
||||
requires Synonymity Assertion or registry crosswalk.
|
||||
- **Identifier assignment is vendor-operated** (D&B), not self-asserted.
|
||||
- **Commercial counterparties rely on DUNS** for risk decisions beyond bare legal existence.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
- DUNS maps to **Proxy Commercial Identifier** (`scheme: 0060`,
|
||||
`authority_class: commercial_proxy`) on **Commercial Record** / **Organization**.
|
||||
- PAYDEX and credit file map to **Evidence Source** influencing **Trust Relationship**
|
||||
and counterparty risk.
|
||||
- UEI maps to **Identifier** (government authoritative) on Commercial Record.
|
||||
- Illustrates user thesis: once credit exposure exists, identity becomes **economically
|
||||
binding** and **reputationally persistent**.
|
||||
- Link to LEI via Synonymity Assertion when same legal entity holds both.
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **DUNS** vs. **LEI**: credit/procurement vs. financial regulatory identifier.
|
||||
- **Business entity (D&B)** vs. **Tenant**: vendor record ≠ SaaS isolation.
|
||||
- **Customer (credit)** vs. **Customer (role)**: credit customer vs. relationship role.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| D&B / procurement concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| DUNS number | Proxy Commercial Identifier (ICD 0060) |
|
||||
| D&B business record | Commercial Record |
|
||||
| PAYDEX | Evidence Source (credit performance) |
|
||||
| UEI | Identifier (government registry) |
|
||||
| Vendor onboarding check | Trust Relationship + Evidence Source |
|
||||
| Parent/branch linkage | Organization structure Relationship |
|
||||
|
||||
## Open Questions
|
||||
|
||||
*(none — settled in `commercial-identity-nuance-settlement.md`)*
|
||||
|
||||
## Settled
|
||||
|
||||
- PAYDEX → Performance Evidence; `numeric_score` optional; tier enum primary.
|
||||
- LEI↔DUNS Synonymity default **medium**.
|
||||
|
||||
## References
|
||||
|
||||
- Dun & Bradstreet DUNS — https://www.dnb.com/duns-number.html
|
||||
- Wikipedia, Data Universal Numbering System — https://en.wikipedia.org/wiki/Data_Universal_Numbering_System
|
||||
- GSA Unique Entity Identifier — https://www.gsa.gov/about-us/organization/federal-acquisition-service/fas-initiatives/integrated-award-environment/iae-systems-information-kit/unique-entity-identifier-update
|
||||
|
|
@ -0,0 +1,102 @@
|
|||
# eIDAS and EUDI Wallet for Legal Persons
|
||||
|
||||
## Source Type
|
||||
|
||||
Regulatory framework and industry analysis. EU eIDAS Regulation, eIDAS 2.0 / EUDI
|
||||
Wallet, European Business Wallet (organizational wallet) initiatives.
|
||||
|
||||
## Domain
|
||||
|
||||
EU digital identity, qualified trust services, legal person credentials, and
|
||||
cross-border commercial trust.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
eIDAS bridges **legal identity** and **commercial trust** at EU scale: electronic
|
||||
signatures, seals, timestamps, and (via EUDI) wallets for natural and **legal
|
||||
persons** carrying verifiable credentials for B2B and B2G exchange.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **eIDAS**: EU regulation for electronic identification and trust services.
|
||||
- **eID (electronic identification)**: national schemes with mutual recognition.
|
||||
- **Qualified trust services**: legally recognized signatures, seals, timestamps, etc.
|
||||
- **Electronic seal**: legal-entity counterpart to personal e-signature.
|
||||
- **EUDI Wallet**: European Digital Identity Wallet for citizens (eIDAS 2.0).
|
||||
- **Organizational / legal person wallet**: extension for companies (EUBW discourse).
|
||||
- **Verifiable credential (EU context)**: credentials in wallet (licenses, compliance certs).
|
||||
- **Transient trust**: real-time verified trust between unknown parties via credentials.
|
||||
- **KYB/KYS**: Know Your Business / Supplier via registry-sourced credentials.
|
||||
- **Delegation of rights**: organizational members present credentials on behalf of legal person.
|
||||
- **Authorization chains**: parent-subsidiary credential issuance hierarchies.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| eIDAS | EU trust framework regulation. |
|
||||
| Qualified signature/seal | Highest assurance trust service. |
|
||||
| Legal person | Company or organization under law. |
|
||||
| EUDI Wallet | EU digital identity wallet. |
|
||||
| Organizational wallet | Wallet for legal person credentials. |
|
||||
| Electronic seal | Entity-level signing mechanism. |
|
||||
| Trust service provider | TSP issuing qualified services. |
|
||||
| Verifiable credential | Attested claim in wallet. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **Natural person and legal person wallets differ materially** — org wallets need
|
||||
delegation, hierarchy, API integration, higher volume.
|
||||
- **Legal person acts through representatives** with scoped credentials (aligns with agency law).
|
||||
- **Qualified services carry legal equivalence** to paper in EU cross-border context.
|
||||
- **Registry-sourced credentials** (e.g., company register) anchor commercial identity to authority.
|
||||
- **Commercial binding increases** when seals/signatures and compliance credentials are used.
|
||||
- **Citizen wallet stack cannot be naively copied** for organizational use cases.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
- Legal person wallet maps to **Organization/Legal Entity** + **Commercial Record** +
|
||||
**Credential** (qualified seal) + **Claim** set.
|
||||
- Representative presenting org credential maps to **Representation Relationship**
|
||||
with scoped **Delegation**.
|
||||
- Registry-issued credential maps to **Claim** with government **Evidence Source**.
|
||||
- Transient trust maps to **Trust Relationship** established at transaction time with
|
||||
VC/qualified credential evidence.
|
||||
- Supports user thesis: commercial credentials make identity **relevant and durable**
|
||||
to counterparties across borders.
|
||||
- Pairwise/pseudonymous identity insufficient for qualified seal; commercial binding
|
||||
requires legal person resolution.
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Legal person (civil law)** vs. **Legal Entity (canon)**: legal person includes natural persons.
|
||||
- **Digital identity (eIDAS)** vs. **Identity Record**: assured ID vs. directory record.
|
||||
- **Trust service** vs. **Trust Relationship**: regulatory service vs. canon relationship.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| eIDAS/EUDI concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| Legal person | Organization / Legal Entity |
|
||||
| Organizational wallet | Commercial Record + Credential store (Scope) |
|
||||
| Electronic seal | Credential (entity signing) |
|
||||
| Qualified certificate | Credential + Assurance Level |
|
||||
| Member presenter | Natural Person + Representation |
|
||||
| Registry credential | Claim + authoritative Evidence Source |
|
||||
| KYB/KYS process | Commercial Relationship onboarding |
|
||||
| Authorization chain | Delegation + org hierarchy Relationships |
|
||||
|
||||
## Open Questions
|
||||
|
||||
*(none — settled in `commercial-identity-nuance-settlement.md`)*
|
||||
|
||||
## Settled
|
||||
|
||||
- Qualified seal → **Credential** `credential_type: qualified_seal` via Representation.
|
||||
- Org wallet → **Scope** `wallet_scope`, linked to Commercial Record — not Tenant.
|
||||
|
||||
## References
|
||||
|
||||
- EU eIDAS Regulation — https://digital-strategy.ec.europa.eu/en/policies/eidas-regulation
|
||||
- EU EUDI Regulation — https://digital-strategy.ec.europa.eu/en/policies/eudi-regulation
|
||||
- Spherity, EUDI Wallet for legal persons — https://www.spherity.com/post/the-european-busienss-wallet-eubw-and-legal-person-identity-redefining-trust-in-the-eu-s-digital
|
||||
|
|
@ -0,0 +1,105 @@
|
|||
# KYC AML and Commercial Identity Binding
|
||||
|
||||
## Source Type
|
||||
|
||||
Regulatory framework synthesis. USA PATRIOT Act CIP, FinCEN KYC/AML, FATF digital
|
||||
identity guidance.
|
||||
|
||||
## Domain
|
||||
|
||||
Financial regulation, customer identification, beneficial ownership, and ongoing
|
||||
commercial relationship monitoring.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
KYC/AML is where governments **mandate** commercial identity binding: institutions
|
||||
must verify who they transact with, retain evidence, and monitor behavior. This is
|
||||
the strongest practical force turning fluid identities into **regulated,
|
||||
high-stakes counterparty records**.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **KYC (Know Your Customer)**: policies ensuring institutions know customers and risks.
|
||||
- **AML (Anti-Money Laundering)**: broader program preventing illicit finance.
|
||||
- **CIP (Customer Identification Program)**: US mandate to verify identity before account opening.
|
||||
- **CDD (Customer Due Diligence)**: risk assessment of customer relationship.
|
||||
- **EDD (Enhanced Due Diligence)**: heightened review for high-risk customers.
|
||||
- **Beneficial owner (BO)**: natural persons owning/controlling legal entity customers
|
||||
(historically 25% threshold; may be lowered for high risk).
|
||||
- **Ongoing monitoring**: transaction surveillance after onboarding.
|
||||
- **Record retention**: CIP records kept years after relationship ends.
|
||||
- **Sanctions / PEP screening**: compare identities against government lists.
|
||||
- **Digital identity (FATF)**: guidance on digital ID assurance for KYC.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| KYC | Know-your-customer compliance program. |
|
||||
| CIP | Customer identification at onboarding. |
|
||||
| Beneficial owner | Natural person behind legal entity customer. |
|
||||
| PEP | Politically exposed person (elevated risk). |
|
||||
| Due diligence | Risk-based identity and activity review. |
|
||||
| Ongoing monitoring | Continued scrutiny of customer activity. |
|
||||
| Risk profile | Customer risk classification. |
|
||||
| FinCEN | US Financial Crimes Enforcement Network. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **Commercial relationship triggers identity rigor** proportional to risk.
|
||||
- **Legal entity customers require beneficial owner identification** — natural
|
||||
persons bound to organization customers.
|
||||
- **Identity verification is not one-time**; monitoring continues across lifecycle.
|
||||
- **Evidence must be retained** even after account closure.
|
||||
- **False identity has regulatory and criminal consequences** — binding is external,
|
||||
not user preference.
|
||||
- **Friction is accepted** where commercial stakes require it.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
- KYC onboarding creates **Commercial Record** + **Commercial Commitment** (regulated
|
||||
relationship) bound to **Natural Person** and/or **Organization/Legal Entity**.
|
||||
- **Beneficial owner** maps to **Natural Person** linked via **Beneficial
|
||||
Ownership Relationship** to Organization/Legal Entity customer (see
|
||||
`beneficial-ownership-kyc-boi.md`).
|
||||
- CIP evidence maps to **Evidence Source** with **Assurance Level**.
|
||||
- Ongoing monitoring produces **Evidence Source** events affecting **Lifecycle State**
|
||||
and **Trust Relationship**.
|
||||
- Supports fluid-to-bound transition: anonymous lead → verified customer with retained proof.
|
||||
- **Account** (bank/login) is insufficient alone; KYC binds the **counterparty**.
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Customer (KYC)** vs. **Customer (Stripe)** vs. **Customer (role)**: regulated
|
||||
counterparty vs. billing object vs. commercial role.
|
||||
- **CIP customer** vs. **Account holder**: verified party vs. access credential.
|
||||
- **Digital identity** vs. **login identity**: assurance-ranked ID vs. session user.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| KYC/AML concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| Verified customer | Commercial Record + Actor binding |
|
||||
| CIP evidence | Evidence Source |
|
||||
| Beneficial owner | Natural Person + Beneficial Ownership Relationship |
|
||||
| Risk profile | Assurance Level + metadata on Commercial Relationship |
|
||||
| EDD review | Evidence Source (enhanced) |
|
||||
| Sanctions hit | Lifecycle State / Trust Relationship revocation |
|
||||
| Transaction alert | Evidence Source event |
|
||||
| Record retention | Lifecycle/archival policy on Commercial Record |
|
||||
|
||||
## Open Questions
|
||||
|
||||
*(none — settled in `commercial-identity-nuance-settlement.md`)*
|
||||
|
||||
## Settled
|
||||
|
||||
- Beneficial Owner → **Beneficial Ownership Relationship**; `control_basis` enum;
|
||||
CDD vs. BOI filing layered separately.
|
||||
|
||||
## References
|
||||
|
||||
- Thomson Reuters, Customer Identification Program overview — https://legal.thomsonreuters.com/blog/overview-customer-identification-program-cip/
|
||||
- Okta KYC definition — https://www.okta.com/identity-101/kyc/
|
||||
- FinCEN, USA PATRIOT Act Section 326 — https://www.fincen.gov/resources/statutes-regulations/usa-patriot-act
|
||||
- FATF Guidance on Digital Identity — https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Guidance-on-Digital-Identity.html
|
||||
|
|
@ -0,0 +1,111 @@
|
|||
# Legal Person, Agency, and Contract Binding
|
||||
|
||||
## Source Type
|
||||
|
||||
Legal doctrine synthesis. Common-law agency principles, contract privity, and
|
||||
juridical person concepts used in commercial law.
|
||||
|
||||
## Domain
|
||||
|
||||
Commercial law foundations for representation, liability, and binding promises
|
||||
between parties.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
Commercial software models "accounts" and "organizations," but courts and
|
||||
regulators reason about **principals, agents, legal persons, and contractual
|
||||
obligations**. Agency law explains how organizations act through people and why
|
||||
commercial identity must bind **liability**, not just login state.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Legal person**: entity recognized by law as holder of rights and duties;
|
||||
includes natural persons and juridical persons (corporations, LLCs, etc.).
|
||||
- **Juridical person**: organization recognized as legal person distinct from
|
||||
members (corporation, association).
|
||||
- **Principal**: party on whose behalf an agent acts.
|
||||
- **Agent**: party authorized to act for principal and bind principal within scope.
|
||||
- **Fiduciary duty**: agent's duty of loyalty and care to principal.
|
||||
- **Actual authority**: express or implied permission granted to agent.
|
||||
- **Apparent authority**: third party reasonably believes agent has authority
|
||||
based on principal's conduct.
|
||||
- **Agency by contract**: principal-agent relationship created by agreement
|
||||
(employment, power of attorney, brokerage).
|
||||
- **Contract**: agreement creating enforceable obligations; requires parties with
|
||||
capacity.
|
||||
- **Privity**: doctrine limiting contract rights/obligations to parties to the
|
||||
contract (with modern statutory exceptions).
|
||||
- **Representation**: agent acts **for** principal; principal may be bound by
|
||||
authorized acts.
|
||||
- **Termination**: agency ends by agreement, operation of law (death, bankruptcy),
|
||||
or breach.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| Principal | Party represented by agent. |
|
||||
| Agent | Party acting on principal's behalf. |
|
||||
| Legal person | Rights-bearing entity under law. |
|
||||
| Juridical person | Non-human legal person (company). |
|
||||
| Fiduciary | Trust-based duty relationship. |
|
||||
| Power of attorney | Written agency authorization. |
|
||||
| Binding | Creating legal obligation on a party. |
|
||||
| Capacity | Legal ability to enter contracts. |
|
||||
| Apparent authority | Authority as seen by third parties. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **Organizations act only through agents** (officers, employees, representatives).
|
||||
- **Commercial binding requires identifiable parties** with legal capacity.
|
||||
- **Representation is contractual or statutory**, not merely technical (API token).
|
||||
- **Principal liability** may attach to unauthorized acts if apparent authority exists.
|
||||
- **Agency terminates**; commercial systems must model lifecycle and revocation.
|
||||
- **Natural person ≠ company** even when sole proprietor; legal structure matters
|
||||
for liability and contract.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
- **Organization** collective actor maps to juridical person when legally recognized.
|
||||
- **Natural Person** maps to natural-person legal person.
|
||||
- **Representation Relationship** in canon aligns with agency (acts for).
|
||||
- **Delegation Relationship** is narrower grant of authority; agency may be broader.
|
||||
- **Commercial Commitment** (contracts, PO acceptance) binds **Legal Entity** or
|
||||
**Organization** actors through **Representation** chains.
|
||||
- Login **Account** does not create agency; employment or explicit authorization does.
|
||||
- **Apparent authority** explains why enterprises must govern service accounts and
|
||||
admin roles carefully (S05, S10, S11).
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Agent (legal)** vs. **Artificial Agent (canon)**: lawyer's agent ≠ AI agent;
|
||||
overlap when AI acts under delegated authority.
|
||||
- **Principal (legal)** vs. **Authorization Principal**: legal principal vs. Cedar principal.
|
||||
- **Legal person** vs. **Legal Entity** in canon: legal person includes natural persons.
|
||||
- **Account holder** vs. **contracting party**: bank account ≠ signatory authority.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| Legal concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| Natural person (legal) | Natural Person |
|
||||
| Juridical person | Organization / Legal Entity |
|
||||
| Principal | Organization or Natural Person (represented party) |
|
||||
| Agent (human) | Natural Person + Representation Relationship |
|
||||
| Agent (org acting) | Organization + Representation Relationship |
|
||||
| Power of attorney | Delegation Relationship + Credential |
|
||||
| Contract | Commercial Commitment (contract) |
|
||||
| Apparent authority | Trust Relationship risk + Administration governance |
|
||||
| Agency termination | Lifecycle State on Representation/Delegation |
|
||||
|
||||
## Open Questions
|
||||
|
||||
- Should canon add **Legal Person** as umbrella for Natural Person + juridical
|
||||
Organization/Legal Entity?
|
||||
- How should apparent authority risks be represented for service accounts?
|
||||
|
||||
## References
|
||||
|
||||
- Stimmel Law, Agency – The Basic Law — https://www.stimmel-law.com/en/articles/agency-basic-law
|
||||
- Contract privity doctrine (common law overview)
|
||||
- Harvard Law School Forum, FinCEN beneficial ownership and corporate persons
|
||||
|
|
@ -0,0 +1,95 @@
|
|||
# LEI and GLEIF Legal Entity Identifier
|
||||
|
||||
## Source Type
|
||||
|
||||
Standard and registry. ISO 17442 Legal Entity Identifier; GLEIF global LEI index.
|
||||
|
||||
## Domain
|
||||
|
||||
Regulated financial markets, legal entity identification, and ownership transparency.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
LEI is the post-2008-crisis global standard for identifying **legal entities** in
|
||||
financial transactions. It encodes **who** and **who owns whom**, making it a
|
||||
canonical example of commercially binding identity with regulatory renewal
|
||||
requirements.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **LEI**: 20-character ISO 17442 identifier for a legal entity.
|
||||
- **Legal entity (LEI scope)**: organization participating in financial transactions;
|
||||
individuals cannot obtain LEI.
|
||||
- **GLEIF**: Global Legal Entity Identifier Foundation; oversees LOUs and data quality.
|
||||
- **LOU (Local Operating Unit)**: issuer/registrar for LEIs in a jurisdiction.
|
||||
- **Level 1 data**: business card data — legal name, address, jurisdiction.
|
||||
- **Level 2 data**: ownership — direct and ultimate parent relationships.
|
||||
- **Renewal**: LEI valid one year; annual renewal required for continued use.
|
||||
- **Regulatory mandate**: 45+ jurisdictions require LEI for certain financial reporting.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| LEI | Legal Entity Identifier code. |
|
||||
| Legal entity | Juridical person in financial markets. |
|
||||
| Level 1 | Entity reference data. |
|
||||
| Level 2 | Parent/ownership reference data. |
|
||||
| GLEIF | Global LEI system operator. |
|
||||
| LOU | Local issuing organization. |
|
||||
| Renewal | Annual reaffirmation of LEI validity. |
|
||||
| Regulator reporting | MiFIR, derivatives reporting, etc. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **LEI identifies legal entities only**, not natural persons or login accounts.
|
||||
- **Ownership is first-class** in LEI Level 2 (parent chains).
|
||||
- **Identity persistence is maintained by renewal**, not immutability of business facts.
|
||||
- **Public global directory** enables counterparty verification.
|
||||
- **LEI does not prove good behavior**; it proves identifiable legal presence.
|
||||
- **One LEI per legal entity** for global financial identification.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
- LEI maps to **Registry Identifier** (`scheme: 0199`, `authority_class:
|
||||
regulatory_global`, `renewal_required: true`) for **Legal Entity** /
|
||||
**Organization** actors.
|
||||
- Level 2 parent data maps to **Ownership** or structural Organization relationships.
|
||||
- LEI record maps to **Commercial Record** or authoritative **Identity Record**
|
||||
with registry **Evidence Source**.
|
||||
- Renewal maps to **Lifecycle State** on Identifier/Commercial Record.
|
||||
- LEI exemplifies **commercial binding**: regulatory participation requires stable,
|
||||
renewed legal identity.
|
||||
- Distinct from DUNS (credit/commerce) and from OIDC sub (authentication).
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Legal entity (LEI)** vs. **Legal Entity (canon)**: aligned when jurisdictionally recognized.
|
||||
- **Legal entity** vs. **Organization**: not every organization has LEI; LEI subset is regulated finance participants.
|
||||
- **LEI** vs. **company registration number**: national registry ID vs. global LEI.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| LEI concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| LEI code | Registry Identifier (regulatory_global, ICD 0199) |
|
||||
| Legal entity | Legal Entity / Organization |
|
||||
| Level 1 data | Commercial Record / registry Profile |
|
||||
| Level 2 parent | Ownership Relationship |
|
||||
| GLEIF registry | Evidence Source (authoritative) |
|
||||
| Annual renewal | Lifecycle State maintenance |
|
||||
| LOU issuance | Issuer Scope + Trust Relationship |
|
||||
|
||||
## Open Questions
|
||||
|
||||
*(none — settled in `commercial-identity-nuance-settlement.md`)*
|
||||
|
||||
## Settled
|
||||
|
||||
- Registry Identifier subtype; LEI↔company reg **strong**; LEI↔DUNS **medium**.
|
||||
|
||||
## References
|
||||
|
||||
- ISO 17442 — https://www.iso.org/standard/78829.html
|
||||
- GLEIF, Introducing the LEI — https://www.gleif.org/en/about-lei/introducing-the-legal-entity-identifier-lei
|
||||
- Wikipedia, Legal Entity Identifier — https://en.wikipedia.org/wiki/Legal_Entity_Identifier
|
||||
|
|
@ -0,0 +1,171 @@
|
|||
# Payment Credential Boundary — PCI and Commercial Commitment
|
||||
|
||||
## Source Type
|
||||
|
||||
Standards and product synthesis. PCI DSS tokenization guidance, Stripe Payment
|
||||
Methods / SetupIntents, and identity-canon Credential vs. Commercial Commitment
|
||||
separation.
|
||||
|
||||
## Domain
|
||||
|
||||
Payment instruments on billing customers — what belongs in canonical identity
|
||||
model vs. PCI-scoped downstream vaults, and how charge authorization relates to
|
||||
Commercial Commitment.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
Stripe **Customer** objects carry **payment methods**, and canon **Credential**
|
||||
already covers secrets and proof material. Collapsing them causes two failures:
|
||||
|
||||
1. **PCI scope bleed** — modeling PAN, CVV, or vault secrets in identity canon
|
||||
implies they belong in general identity stores.
|
||||
2. **Semantic collision** — login passkeys and payment mandates both "authorize
|
||||
something" but authorize **authentication** vs. **commercial debit**.
|
||||
|
||||
Payment methods are commercially binding (tier 3 assurance) when they encode
|
||||
**mandate to charge** — but the binding artifact is the **authorization/commitment**,
|
||||
not the token reference.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
### PCI DSS data categories
|
||||
|
||||
- **CHD (cardholder data)**: PAN, cardholder name, expiration, service code.
|
||||
- **Sensitive authentication data (SAD)**: CVV/CVC, full track data, PIN — never
|
||||
stored after authorization per PCI.
|
||||
- **Token**: surrogate value replacing PAN; if properly implemented, token in
|
||||
merchant environment is **out of PCI CHD scope** (PCI tokenization guidelines).
|
||||
- **Scope principle**: systems that store, process, or transmit CHD fall under PCI;
|
||||
token references (`pm_xxx`) in app DBs are not CHD when only the token exists.
|
||||
|
||||
### Stripe payment object model
|
||||
|
||||
- **PaymentMethod** (`pm_xxx`): reusable payment details attached to Customer;
|
||||
contains type-specific non-transaction data (last4, fingerprint, billing details).
|
||||
- **SetupIntent**: establishes future off-session payment — creates mandate to charge.
|
||||
- **PaymentIntent**: one-time or reusable charge attempt.
|
||||
- **Customer**: billing container; payment methods attach here, not to login User.
|
||||
- **Mandates** (SEPA, Bacs, etc.): explicit customer authorization for debits.
|
||||
|
||||
### Authentication vs. payment authorization
|
||||
|
||||
| Dimension | Authentication credential | Payment authorization |
|
||||
| --- | --- | --- |
|
||||
| Proves | Identity / session control | Right to debit funds |
|
||||
| Scope | IdP, app login, federation | Payment network / acquirer |
|
||||
| Regulation | NIST 800-63, OIDC | PCI DSS, PSD2 SCA, Nacha |
|
||||
| Canon home | Credential | Payment Mandate (Commercial Commitment) |
|
||||
| Secret handling | Passkey, password hash | CHD in vault only; token ref in app |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **Canon is implementation-neutral** but must not encourage CHD in identity layers.
|
||||
- **Payment provider owns payment truth**; app holds references and commitment state.
|
||||
- **Reusable payment method** implies **Commercial Commitment** (payment mandate)
|
||||
when customer consented to future charges (SetupIntent succeeded, card on file).
|
||||
- **Single-use payment methods** may exist only for one PaymentIntent — weaker
|
||||
commitment, often no reusable mandate.
|
||||
- **Subscription** is separate Commercial Commitment (recurring service obligation);
|
||||
payment mandate is **enabling** commitment for collection.
|
||||
- **Webhook events** (`setup_intent.succeeded`, `payment_method.attached`) are
|
||||
**Evidence Source** for mandate lifecycle.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
### Resolved: do not map payment methods to Credential
|
||||
|
||||
**Credential** in canon covers authentication, federation, and entitlement proof
|
||||
(passkey, password, certificate, VC). **Payment methods are not Credentials.**
|
||||
|
||||
Raw CHD and SAD are **out of canon entirely** — downstream PCI vault / payment
|
||||
provider only.
|
||||
|
||||
### Payment Instrument Reference
|
||||
|
||||
Add **Payment Instrument Reference** — Reference layer value scoped to a payment
|
||||
provider (Stripe `pm_xxx`, fingerprint, display last4, mandate ID). Links to
|
||||
**Commercial Record**, not to login **Account**.
|
||||
|
||||
Properties:
|
||||
|
||||
- `provider_scope` — Stripe account, Adyen merchant, etc.
|
||||
- `instrument_type` — card, sepa_debit, us_bank_account, etc.
|
||||
- `reference_id` — provider token (not PAN).
|
||||
- `reusable` — boolean.
|
||||
- `lifecycle_state` — attached, detached, expired, revoked.
|
||||
|
||||
This is a **Scoped Identifier** specialization, not a Credential.
|
||||
|
||||
### Payment Mandate as Commercial Commitment
|
||||
|
||||
When a customer authorizes future charges (SetupIntent success, SEPA mandate
|
||||
signed, card saved with explicit consent), model **Payment Mandate** as a
|
||||
**Commercial Commitment** subtype:
|
||||
|
||||
- `commitment_type: payment_mandate`
|
||||
- `lifecycle_state`: proposed → active → revoked → expired
|
||||
- Parties: customer actor (via Commercial Record) and vendor/payment facilitator
|
||||
- **Evidence Source**: SetupIntent result, mandate document, SCA proof metadata
|
||||
- `assurance_tier: committed` on Counterparty Assurance Gradient
|
||||
|
||||
**Subscription** remains `commitment_type: subscription` — distinct but often
|
||||
co-created at checkout.
|
||||
|
||||
### Commercial Record role
|
||||
|
||||
**Commercial Record** (Stripe Customer) **references** payment instrument refs
|
||||
and **hosts** links to Payment Mandate commitments. Do not embed CHD attributes
|
||||
in Commercial Record canon fields — only provider references and lifecycle flags
|
||||
(`delinquent`, default payment method ref).
|
||||
|
||||
### Layer diagram
|
||||
|
||||
```text
|
||||
Login Account → Credential (passkey, password)
|
||||
Commercial Record → Payment Instrument Reference (pm_xxx)
|
||||
Commercial Commitment → Payment Mandate + Subscription
|
||||
PCI Vault / Stripe → CHD (downstream only, not canon)
|
||||
Evidence Source → webhooks, mandate PDF, SCA audit
|
||||
```
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Payment method (Stripe)** vs. **Credential (canon)**: both grant "permission"
|
||||
but different permission domains.
|
||||
- **Payment credential (informal)** vs. **Credential (glossary)**: avoid informal
|
||||
phrase in canonical definitions; use Payment Instrument Reference + Payment Mandate.
|
||||
- **Saved card** vs. **payment mandate**: saved token may exist before explicit
|
||||
off-session mandate — lifecycle `proposed` until SetupIntent completes.
|
||||
- **customer_account (Stripe)** vs. **Account (login)**: reinforces commercial split.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| Source artifact | Canonical mapping |
|
||||
| --- | --- |
|
||||
| PAN / CVV | Out of canon (PCI downstream) |
|
||||
| PaymentMethod `pm_xxx` | Payment Instrument Reference |
|
||||
| SetupIntent succeeded | Payment Mandate Commercial Commitment + Evidence |
|
||||
| Subscription object | Commercial Commitment (subscription) |
|
||||
| Default payment method | Reference on Commercial Record |
|
||||
| Payment webhook | Evidence Source |
|
||||
| 3DS / SCA step-up | Evidence Source on mandate (not Credential) |
|
||||
| Passkey for login | Credential (unchanged) |
|
||||
|
||||
## Open Questions
|
||||
|
||||
*(none — settled in `commercial-identity-nuance-settlement.md`)*
|
||||
|
||||
## Settled
|
||||
|
||||
- Network tokens → Payment Instrument Reference `instrument_type: network_token`.
|
||||
- Shared methods → multi Commercial Record link within payment org Scope.
|
||||
- Wallet balance → Commercial Record `provider_ledger_balance` attribute.
|
||||
|
||||
## References
|
||||
|
||||
- PCI SSC, Tokenization Guidelines — https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf
|
||||
- Stripe Payment Methods — https://docs.stripe.com/payments/payment-methods
|
||||
- Stripe Customer object — https://docs.stripe.com/api/customers/object
|
||||
- Stripe SetupIntent — https://docs.stripe.com/api/setup_intents
|
||||
- Internal: `../commercial-subscription/stripe-customer-billing.md`,
|
||||
`reputation-assurance-gradient.md`, `commercial-identity-synthesis.md`
|
||||
|
|
@ -0,0 +1,186 @@
|
|||
# Registry Identifier Subtypes — ISO 6523, ALEI, LEI, DUNS, UEI
|
||||
|
||||
## Source Type
|
||||
|
||||
Standards and registry synthesis. ISO/IEC 6523, ISO 17442 (LEI), ISO 8000-116
|
||||
(ALEI), GLEIF, D&B DUNS, SAM.gov UEI, EITI/Open Ownership identifier guidance.
|
||||
|
||||
## Domain
|
||||
|
||||
Authoritative and proxy organization identifiers used in commerce, procurement,
|
||||
financial markets, beneficial ownership transparency, and master data management.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
Legal entities accumulate **multiple identifiers** from different registries —
|
||||
company registration numbers, LEI, DUNS, UEI, VAT — each with different
|
||||
**issuing authority**, **renewal rules**, and **trust basis**. Collapsing them
|
||||
into generic Identifier loses lifecycle, authority, and cross-registry linking
|
||||
semantics needed for commercial binding and BO transparency.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
### ISO/IEC 6523 structure
|
||||
|
||||
ISO/IEC 6523 defines organization identification as:
|
||||
|
||||
- **International Code Designator (ICD)**: up to 4 digits identifying the issuing
|
||||
scheme authority (registered with ISO/IEC 6523-2).
|
||||
- **Organization identifier**: up to 35 characters within that scheme.
|
||||
- **Optional organization part identifier (OPI)**: sub-entity within organization.
|
||||
|
||||
Combined form enables global interchange (PEPPOL, EDIFACT, Schema.org `iso6523Code`).
|
||||
|
||||
Example ICD allocations relevant to commercial identity:
|
||||
|
||||
| ICD | Scheme | Authority type |
|
||||
| --- | --- | --- |
|
||||
| 0060 | D-U-N-S (DUNS) | Commercial proxy (D&B) |
|
||||
| 0088 | EAN Location Code (GLN) | GS1 location |
|
||||
| 0151 | Singapore UEN | Government registry |
|
||||
| 0199 | Legal Entity Identifier (LEI) | GLEIF / ISO 17442 |
|
||||
| 0209 | GS1 identification keys | GS1 |
|
||||
|
||||
(Full list maintained at iso6523.info and PEPPOL ICD codelists.)
|
||||
|
||||
### Authoritative vs. proxy identifiers (ISO 8000-116 / ALEI)
|
||||
|
||||
**Authoritative Legal Entity Identifier (ALEI)**: identifier assigned by a
|
||||
**government jurisdiction** authorized by statute to create legal entities and
|
||||
maintain authoritative registries. Format: jurisdiction prefix + register +
|
||||
local number (e.g., `US-DE.BER:3031657`).
|
||||
|
||||
**Proxy identifiers**: issued by institutions that do **not** create legal
|
||||
entities — DUNS (D&B), NCAGE (CAGE), and arguably LEI (GLEIF issues to existing
|
||||
legal entities but does not incorporate them).
|
||||
|
||||
**LEI nuance**: ISO 17442 / GLEIF is regulatory-mandated for financial
|
||||
transactions but is a **cross-jurisdiction overlay** on existing legal entities,
|
||||
not the incorporating register. Canon treats LEI as **Registry Identifier**
|
||||
with `authority_class: regulatory_global`.
|
||||
|
||||
### Renewal and lifecycle
|
||||
|
||||
| Identifier | Renewal / validity | Lifecycle driver |
|
||||
| --- | --- | --- |
|
||||
| LEI | Annual renewal required | GLEIF / LOU reaffirmation |
|
||||
| DUNS | No annual renewal; record updates | D&B data maintenance |
|
||||
| UEI | Persistent in SAM.gov | Entity registration status |
|
||||
| Company reg number | Jurisdiction-specific | Annual report / dissolution |
|
||||
| ALEI / IBRN | Tied to registry filing status | Government register |
|
||||
| VAT / tax ID | Jurisdiction-specific | Tax authority |
|
||||
|
||||
Renewal semantics belong on **Registry Identifier** lifecycle state, not on the
|
||||
Organization actor.
|
||||
|
||||
### Cross-registry linking
|
||||
|
||||
Same legal entity may hold LEI + DUNS + UEI + national company number.
|
||||
**Synonymity Assertion** (`same_as`, strong or authoritative) links Registry
|
||||
Identifiers when evidenced by registry crosswalk, LOU verification, or operator
|
||||
confirmation. Do not silently merge Commercial Records.
|
||||
|
||||
EITI and Open Ownership recommend **reliable organizational identifiers**
|
||||
(especially authoritative registration numbers) in beneficial ownership datasets
|
||||
to disambiguate corporate vehicles.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| Registry Identifier | Identifier issued under a registered scheme with known authority. |
|
||||
| ICD | ISO 6523 International Code Designator for a scheme. |
|
||||
| ALEI | Authoritative Legal Entity Identifier (government register). |
|
||||
| Proxy identifier | Commercial or overlay ID not from incorporating authority. |
|
||||
| LOU | Local Operating Unit issuing LEIs. |
|
||||
| Renewal | Periodic reaffirmation of identifier validity (esp. LEI). |
|
||||
| Crosswalk | Mapping between identifiers for same entity. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **Registry Identifier is an Identifier subtype**, not a Record layer entity.
|
||||
The registry **record** (GLEIF entry, D&B profile, SAM registration) maps to
|
||||
Commercial Record or Identity Record.
|
||||
- **Authority class** matters more than brand name (LEI vs. DUNS vs. company reg).
|
||||
- **Renewal is optional metadata** — present for LEI, absent for DUNS.
|
||||
- **ICD code** is the preferred `scheme` key for ISO 6523-aligned identifiers.
|
||||
- **Proxy Commercial Identifier** is a Registry Identifier with
|
||||
`authority_class: commercial_proxy` for DUNS-like schemes.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
### Resolved: Registry Identifier subtype
|
||||
|
||||
Add **Registry Identifier** as an Identifier specialization in the Reference layer.
|
||||
|
||||
**Recommended fields:**
|
||||
|
||||
- `scheme`: ICD code or well-known scheme URI (e.g., `0199` for LEI, `0060` for DUNS)
|
||||
- `authority`: issuing body (GLEIF LOU, D&B, SAM.gov, Companies House, etc.)
|
||||
- `authority_class`: `government_registry` | `regulatory_global` | `commercial_proxy` | `tax`
|
||||
- `jurisdiction`: ISO country/subdivision when applicable
|
||||
- `value`: the identifier string
|
||||
- `renewal_required`: boolean
|
||||
- `lifecycle_state`: active, lapsed, revoked, expired, superseded
|
||||
- `last_renewed_at` / `expires_at`: when renewal applies
|
||||
- `evidence_source`: registry lookup, LOU issuance, API verification
|
||||
|
||||
### Proxy Commercial Identifier
|
||||
|
||||
**Proxy Commercial Identifier** is a Registry Identifier with
|
||||
`authority_class: commercial_proxy` — vendor-operated business keys (DUNS) used
|
||||
for credit and procurement but not legal incorporation. Keeps DUNS mapping
|
||||
explicit without conflating with ALEI or company registration numbers.
|
||||
|
||||
### Mapping table
|
||||
|
||||
| Source identifier | Canonical mapping |
|
||||
| --- | --- |
|
||||
| LEI code | Registry Identifier (`scheme: 0199`, `authority_class: regulatory_global`) |
|
||||
| DUNS | Proxy Commercial Identifier (`scheme: 0060`) |
|
||||
| UEI (SAM.gov) | Registry Identifier (`authority_class: government_registry`, US federal) |
|
||||
| Company registration number | Registry Identifier (`authority_class: government_registry`, jurisdiction-local) |
|
||||
| ALEI / IBRN | Registry Identifier (`authority_class: government_registry`, ISO 8000-116 format) |
|
||||
| VAT / EIN / tax ID | Registry Identifier (`authority_class: tax`) |
|
||||
| GLEIF registry entry | Commercial Record or Identity Record + Evidence Source |
|
||||
| D&B business profile | Commercial Record + PAYDEX as Evidence Source |
|
||||
| Same entity, multiple IDs | Synonymity Assertion between Registry Identifiers |
|
||||
|
||||
### Relationship to Beneficial Ownership
|
||||
|
||||
BO datasets should reference **Organization/Legal Entity** via Registry Identifier
|
||||
(authoritative company reg preferred; LEI as strong cross-border key). Beneficial
|
||||
Ownership Relationships attach to the entity actor, not to the identifier — but
|
||||
identifier quality affects Evidence strength on BO filings.
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Legal entity (LEI)** vs. **Organization (canon)**: LEI subset ⊂ organizations
|
||||
with financial/regulatory participation.
|
||||
- **DUNS business entity** vs. **Legal Entity**: D&B may assign DUNS to locations
|
||||
or branches not identical to juridical persons.
|
||||
- **Identifier** vs. **Commercial Record**: Stripe `customer_id` is scoped
|
||||
system Identifier; LEI is registry Identifier — different authority classes.
|
||||
|
||||
## Open Questions
|
||||
|
||||
*(none — settled in `commercial-identity-nuance-settlement.md`)*
|
||||
|
||||
## Settled
|
||||
|
||||
- `authority_class` includes `industry_association` (NCAGE, GS1 GLN).
|
||||
- LEI↔DUNS medium; LEI↔company reg/ALEI/UEI strong; crosswalk table in settlement note.
|
||||
- OPI → Organization Unit / branch Registry Identifier with `organization_part_id`.
|
||||
|
||||
## References
|
||||
|
||||
- ISO/IEC 6523 — https://www.iso.org/standard/25773.html
|
||||
- ISO 17442 (LEI) — https://www.iso.org/standard/78829.html
|
||||
- ISO 8000-116 (ALEI) — https://www.iso.org/standard/75117.html
|
||||
- GLEIF, Introducing the LEI — https://www.gleif.org/en/about-lei/introducing-the-legal-entity-identifier-lei
|
||||
- iso6523.info ICD list — http://iso6523.info/icd_list.pdf
|
||||
- PEPPOL ICD codelist — https://docs.peppol.eu/poacc/billing/3.0/codelist/ICD/
|
||||
- GSA, Unique Entity Identifier — https://www.gsa.gov/about-us/organization/federal-acquisition-service/fas-initiatives/integrated-award-environment/iae-systems-information-kit/unique-entity-identifier-update
|
||||
- EITI, Organisational identifiers guidance — https://eiti.org/sites/default/files/2023-11/Technical%20Guidance%20%E2%80%93%20Organisational%20identifiers%20guidance%20%20WEB.pdf
|
||||
- Open Ownership, reliable identifiers — https://www.openownership.org/en/publications/using-reliable-identifiers-for-corporate-vehicles-in-beneficial-ownership-data/
|
||||
- Internal: `lei-gleif-legal-entity-identifier.md`, `duns-commercial-credit-identity.md`
|
||||
|
|
@ -0,0 +1,242 @@
|
|||
# Reputation and Counterparty Assurance Gradient
|
||||
|
||||
## Source Type
|
||||
|
||||
Cross-domain synthesis. Online reputation systems, credit reporting, contract
|
||||
bonding theory, payment dispute automation, and alternative dispute resolution
|
||||
(ADR) / litigation practice.
|
||||
|
||||
## Domain
|
||||
|
||||
How counterparties move from weak social proof to enforceable commercial reliance
|
||||
— and how identity-canon should model that journey without collapsing tiers.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
"Reputation" is overloaded: a five-star Yelp review, a D&B PAYDEX score, a
|
||||
performance bond, and a court judgment all influence whether a counterparty is
|
||||
trusted — but they differ radically in **evidence quality**, **gaming risk**,
|
||||
**attribution strength**, and **enforceability**. Software often stores them in
|
||||
one "rating" field. Canon must preserve the gradient so downstream systems do not
|
||||
treat gamable opinion as legal fact or ignore contractual stakes already modeled
|
||||
elsewhere.
|
||||
|
||||
## The Assurance Gradient (Journey)
|
||||
|
||||
Counterparty assurance typically escalates through four tiers. Higher tiers do
|
||||
not replace lower ones; they **constrain** how much weight lower tiers may carry
|
||||
for a given decision.
|
||||
|
||||
```text
|
||||
Tier 1 OPINION Star ratings, reviews, karma, badges
|
||||
(weak/gamable) Low cost to fake; Sybil-prone; scope-local
|
||||
|
||||
Tier 2 OBSERVED PAYDEX, on-time %, chargeback rate, audit logs,
|
||||
(evidence) verified transaction history, KYC outcome
|
||||
|
||||
Tier 3 COMMITTED Contract, bond, escrow, guarantee, insurance,
|
||||
(financial) SLA penalties, payment mandate, subscription lock-in
|
||||
|
||||
Tier 4 ADJUDICATED Arbitration award, court judgment, regulator action,
|
||||
(legal) enforced settlement, lien, bankruptcy filing
|
||||
```
|
||||
|
||||
### Tier 1 — Opinion signals (weak, gamable)
|
||||
|
||||
**Examples:** Amazon/Yelp star ratings, eBay feedback scores, Stack Overflow
|
||||
reputation, Uber driver rating, Trustpilot reviews, Airbnb host score.
|
||||
|
||||
**Properties:**
|
||||
|
||||
- **Low cost of manipulation** — fake reviews, review bombing, sock puppets,
|
||||
Sybil accounts (Jøsang reputation attack taxonomy).
|
||||
- **Scope-local** — reputation on eBay does not transfer to Etsy without
|
||||
explicit portability (reputation bank problem).
|
||||
- **Voluntary participation bias** — satisfied and angry customers over-represent;
|
||||
silent majority absent.
|
||||
- **Identity attribution weak** — reviewer may be unverified persona; linkage to
|
||||
Natural Person or Organization often absent.
|
||||
- **Economic effect real but bounded** — eBay seller ratings correlate with price
|
||||
premium, but platforms add escrow and buyer protection because ratings alone
|
||||
insufficient.
|
||||
|
||||
**Canon mapping:** **Reputation Signal** — an **Evidence Source** with
|
||||
`assurance_tier: opinion`. Attach to **Profile**, **Commercial Record**, or
|
||||
**Actor** with explicit **Scope** (platform namespace). Default synonymity and
|
||||
trust strength: **weak**. Do not promote to Commercial Commitment.
|
||||
|
||||
**Gaming defenses (downstream):** verified-purchase flags, rate limits, graph
|
||||
analysis, moderation — model as separate Evidence Source metadata, not as tier
|
||||
upgrade by itself.
|
||||
|
||||
### Tier 2 — Observed metrics (evidence-based)
|
||||
|
||||
**Examples:** D&B PAYDEX, business credit scores, platform completion rate,
|
||||
on-time delivery statistics, SLA attainment dashboards, chargeback ratio,
|
||||
sanctions-screen clear result, KYC pass, LEI renewal status.
|
||||
|
||||
**Properties:**
|
||||
|
||||
- **Grounded in observable events** — payment dates, shipment scans, registry
|
||||
lookups, transaction logs.
|
||||
- **Stronger attribution** — usually tied to **Registry Identifier**, **Commercial
|
||||
Record**, or verified **Account** history.
|
||||
- **Third-party or platform issuer** — D&B, credit bureaus, marketplace operator,
|
||||
KYC vendor acts as **Evidence Source** issuer.
|
||||
- **Still revisable** — metrics update; disputes may correct; not legally
|
||||
conclusive.
|
||||
- **Monitoring lifecycle** — ongoing CDD and PAYDEX refresh mirror **Lifecycle
|
||||
State** on evidence, not one-time truth.
|
||||
|
||||
**Canon mapping:** **Performance Evidence** — **Evidence Source** with
|
||||
`assurance_tier: observed`. Link to **Commercial Record** / **Organization** via
|
||||
**Registry Identifier** or **Commercial Relationship**. Supports **Trust
|
||||
Relationship** with medium-to-strong confidence when issuer is authoritative.
|
||||
|
||||
### Tier 3 — Committed stakes (contractual / financial)
|
||||
|
||||
**Examples:** Performance bonds, surety bonds, letters of credit, escrow deposits,
|
||||
service-level agreements with liquidated damages, signed MSAs, active subscription
|
||||
with payment mandate, insurance certificates, qualified electronic seals on
|
||||
contracts (eIDAS).
|
||||
|
||||
**Properties:**
|
||||
|
||||
- **Costly to breach** — Klein-Leffler bonding: quality assurance through
|
||||
market forces when reputation alone insufficient; hostages and penalties.
|
||||
- **Explicit parties** — **Legal Person** / **Organization** actors bound via
|
||||
**Commercial Commitment** and **Representation** chains.
|
||||
- **Automated enforcement partial** — smart-contract escrow, Stripe retention,
|
||||
auto-renewal billing, SLA breach triggers — automation executes **committed**
|
||||
rules without yet reaching court.
|
||||
- **Identity stakes rise** — counterparties need stable **Registry Identifier**,
|
||||
**Commercial Record**, and often **Beneficial Ownership Relationship** because
|
||||
liability is real.
|
||||
|
||||
**Canon mapping:** **Commercial Commitment** (contract, subscription, payment
|
||||
mandate, bond) with **Evidence Source** attesting execution. Assurance tier:
|
||||
`committed`. **Trust Relationship** here should cite the commitment ID, not
|
||||
opinion aggregates.
|
||||
|
||||
**Distinction:** A five-star rating is not a bond. A bond is not a review.
|
||||
Model separately; combine only in downstream risk engines with explicit weighting.
|
||||
|
||||
### Tier 4 — Adjudicated outcomes (automated dispute → legal resolution)
|
||||
|
||||
**Escalation path:**
|
||||
|
||||
1. **Platform automation** — chargeback dispute rules, marketplace arbitration
|
||||
(eBay Money Back Guarantee), payment processor outcome.
|
||||
2. **Contractual ADR** — mandatory arbitration clause (AAA, ICC, JAMS); neutral
|
||||
award binding per contract and statute.
|
||||
3. **Courts** — breach of contract, fraud, collections, judgment lien, bankruptcy.
|
||||
|
||||
**Properties:**
|
||||
|
||||
- **Third-party or state authority** — arbitrator, court, regulator issues outcome.
|
||||
- **High attribution** — parties identified in proceeding; ties to **Legal Entity**.
|
||||
- **Enforceable beyond platform** — judgments attach to legal persons; credit
|
||||
reporting may follow.
|
||||
- **Lifecycle durable** — satisfied, appealed, vacated, enforced — explicit
|
||||
**Lifecycle State**.
|
||||
|
||||
**Canon mapping:** **Adjudication Outcome** — **Evidence Source** with
|
||||
`assurance_tier: adjudicated`. May trigger **Commercial Commitment** state change
|
||||
(breached, fulfilled), **Trust Relationship** revocation, or **Lifecycle State**
|
||||
on **Commercial Record**. Do not model as "bad review."
|
||||
|
||||
## Cross-Tier Dynamics
|
||||
|
||||
| Transition | What changes | Canon event |
|
||||
| --- | --- | --- |
|
||||
| Opinion → Observed | Platform verifies purchase; metric computed from logs | New Performance Evidence; optional Synonymity link reviewer Account to transaction |
|
||||
| Observed → Committed | Parties sign contract / post bond | Commercial Commitment created; Trust Relationship cites commitment |
|
||||
| Committed → Adjudicated | Breach → ADR/court | Adjudication Outcome Evidence; commitment lifecycle update |
|
||||
| Adjudicated → Observed | Judgment paid; credit file updated | Performance Evidence refresh (credit bureau) |
|
||||
|
||||
**De-escalation:** Adjudicated fraud finding may **invalidate** opinion signals
|
||||
(moderation) but should not silently delete Evidence — supersede with lifecycle.
|
||||
|
||||
**Identity coupling:** Higher tiers require stronger **actor attribution**.
|
||||
Opinion may attach to **Persona**; adjudication attaches to **Legal Entity** +
|
||||
**Registry Identifier**.
|
||||
|
||||
## Relationship to Existing Canon
|
||||
|
||||
| Concept | Role in assurance gradient |
|
||||
| --- | --- |
|
||||
| Evidence Source | Carrier for all tiers; use `assurance_tier` metadata |
|
||||
| Trust Relationship | Counterparty reliance; must cite tier basis |
|
||||
| Commercial Commitment | Tier 3 anchor |
|
||||
| Commercial Relationship | Scope for which assurance applies |
|
||||
| Registry Identifier | Attribution for tiers 2–4 |
|
||||
| Beneficial Ownership Relationship | Liability chain for tier 3–4 entity customers |
|
||||
| Assurance Level (NIST) | Orthogonal — identity/auth proofing, not commercial performance |
|
||||
| Synonymity Assertion | Link platform persona to legal entity when tiers mix |
|
||||
|
||||
## Reputation Systems Literature (Practical)
|
||||
|
||||
Jøsang survey and Resnick criteria for effective reputation systems:
|
||||
|
||||
1. Long-lived entities with predictable future interaction.
|
||||
2. Capture and distribute feedback from prior interactions.
|
||||
3. Use feedback to guide trust.
|
||||
|
||||
**Implication for canon:** Tier 1 only works when **Scope** is stable and
|
||||
interaction history is modeled as Evidence with temporal bounds. Reputation
|
||||
**capital** (economic value of good history) is aggregate **Performance Evidence**
|
||||
over time — not a separate ontological root.
|
||||
|
||||
**Attacks:** self-promotion, Sybil, slandering, whitewashing — map to
|
||||
`integrity_risk` metadata on opinion-tier Evidence; downstream concern, but canon
|
||||
should flag tier-1 default weakness.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| Source artifact | Canonical mapping |
|
||||
| --- | --- |
|
||||
| Star rating / review | Reputation Signal (Evidence Source, tier: opinion) |
|
||||
| Verified purchase review | Reputation Signal + Performance Evidence link |
|
||||
| PAYDEX / credit score | Performance Evidence (tier: observed) |
|
||||
| SLA dashboard | Performance Evidence on Commercial Relationship |
|
||||
| Signed MSA / bond | Commercial Commitment + Evidence Source (tier: committed) |
|
||||
| Escrow release | Commercial Commitment lifecycle event |
|
||||
| Arbitration award | Adjudication Outcome (tier: adjudicated) |
|
||||
| Court judgment | Adjudication Outcome + may affect Legal Entity lifecycle |
|
||||
| "Trust score" UI | Downstream projection — not canonical root |
|
||||
|
||||
## Resolved Canon Question
|
||||
|
||||
**Do not add Reputation as a first-class entity.**
|
||||
|
||||
Instead:
|
||||
|
||||
1. **Counterparty Assurance Gradient** — modeling pattern (four tiers).
|
||||
2. **Evidence Source** specializations by tier: **Reputation Signal** (opinion),
|
||||
**Performance Evidence** (observed), **Adjudication Outcome** (adjudicated);
|
||||
tier 3 uses existing **Commercial Commitment**.
|
||||
3. **Trust Relationship** carries `assurance_basis` referencing tier + evidence IDs.
|
||||
|
||||
**Convenience term only:** "Reputation" in prose — resolve to specific tier and
|
||||
Evidence Source before modeling.
|
||||
|
||||
## Open Questions
|
||||
|
||||
*(none — settled in `commercial-identity-nuance-settlement.md`)*
|
||||
|
||||
## Settled
|
||||
|
||||
- `assurance_tier` primary; optional `numeric_score` + `score_scale` downstream.
|
||||
- Segregated escrow → Commercial Commitment `commitment_type: escrow`.
|
||||
- Reputation portability → Synonymity `linked_to`, weak default.
|
||||
- Oracle release → observed; ADR/court → adjudicated.
|
||||
|
||||
## References
|
||||
|
||||
- Josang, "A survey of trust and reputation systems for online service provision" — https://doi.org/10.1016/j.dss.2005.05.019
|
||||
- Hoffman et al., "A survey of attack and defense techniques for reputation systems" — ACM Computing Surveys
|
||||
- Klein and Leffler (1981), quality assurance through bonding / price premiums
|
||||
- RFC 7070, An Architecture for Reputation Reporting — https://www.rfc-editor.org/rfc/rfc7070
|
||||
- Wikipedia, Reputation system — https://en.wikipedia.org/wiki/Reputation_system
|
||||
- Internal: `commercial-trust-binding-theory.md`, `duns-commercial-credit-identity.md`,
|
||||
`legal-person-agency-contract.md`, `kyc-aml-commercial-identity-binding.md`
|
||||
|
|
@ -0,0 +1,94 @@
|
|||
# Salesforce CRM Commercial Record Model
|
||||
|
||||
## Source Type
|
||||
|
||||
Product data model reference. Salesforce Account, Contact, Lead, and B2B relationship patterns.
|
||||
|
||||
## Domain
|
||||
|
||||
CRM, sales operations, commercial customer records, and B2B account hierarchies.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
Salesforce **Account** is the archetypal **commercial record** in enterprise software:
|
||||
a company or household you sell to, distinct from **Contact** (people) and **User**
|
||||
(login). It operationalizes commercial identity separate from authentication.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Account**: company, household, or partner organization in CRM; core commercial record.
|
||||
- **Contact**: person associated with accounts; human relationship endpoint.
|
||||
- **Lead**: unqualified prospect before conversion to Account/Contact.
|
||||
- **Opportunity**: potential revenue deal tied to Account.
|
||||
- **Account hierarchy**: parent-child account relationships (global HQ → subsidiaries).
|
||||
- **Account-Contact Relationship**: many-to-many person-to-account roles (ACR).
|
||||
- **Person Account**: B2C pattern merging person and account for individual consumers.
|
||||
- **Partner / Customer / Competitor**: account type labels for commercial role hints.
|
||||
- **User (Salesforce)**: internal login for CRM operators, not customer identity.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| Account | CRM commercial entity record. |
|
||||
| Contact | Person linked to accounts. |
|
||||
| Lead | Pre-qualification prospect. |
|
||||
| ACR | Account-Contact Relationship with roles. |
|
||||
| Account hierarchy | Parent/child commercial structure. |
|
||||
| Person Account | B2C combined person+account pattern. |
|
||||
| Customer account (informal) | Often means CRM Account object. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **Commercial party (Account) ≠ login User**; sales data outlives individual logins.
|
||||
- **Multiple contacts** represent people acting for commercial account (agency in practice).
|
||||
- **Hierarchy models corporate structure** for roll-up revenue and ownership context.
|
||||
- **Lead → Account conversion** is fluid-to-bound transition in commercial funnel.
|
||||
- **Person Account** blurs person/account boundary for B2C — convenient but risky for canon purity.
|
||||
- **Account type** hints customer/vendor/partner but is not authorization.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
- Salesforce **Account** maps to **Commercial Record** linked to **Organization**
|
||||
(B2B) or **Natural Person** (person account).
|
||||
- **Contact** maps to **Natural Person** + **Affiliation** or **Representation** to Organization.
|
||||
- **ACR** maps to **Membership** or **Representation** with role metadata.
|
||||
- **Account hierarchy** maps to Organization parent/child structural relationships.
|
||||
- **Lead** maps to provisional Identity/Commercial prospect with weak evidence until conversion.
|
||||
- **User** maps to internal **Account** (employee), not customer.
|
||||
- Validates Commercial Record concept from Customer Account resolution work.
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Account (CRM)** vs. **Account (login)**: Salesforce naming collision.
|
||||
- **Customer account** language vs. **Account object**: product uses Account for all.
|
||||
- **Person Account** vs. **P2 separation**: B2C shortcut vs. canon layers.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| Salesforce concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| Account (B2B) | Commercial Record + Organization |
|
||||
| Contact | Natural Person |
|
||||
| Account-Contact Relationship | Affiliation / Representation |
|
||||
| Account hierarchy | Organization structure Relationship |
|
||||
| Lead | Prospective Commercial Record (weak) |
|
||||
| Opportunity | Pipeline Pursuit (promotes to Commercial Commitment on binding trigger) |
|
||||
| User | Account (internal operator) |
|
||||
| Person Account | Commercial Record + Natural Person (combined projection) |
|
||||
|
||||
## Open Questions
|
||||
|
||||
*(none — settled in `commercial-identity-nuance-settlement.md`)*
|
||||
|
||||
## Settled
|
||||
|
||||
- Opportunity → **Pipeline Pursuit**; binding triggers and renewal/amendment rules.
|
||||
- Person Account → split Natural Person + Commercial Record; adapter `projection_mode`
|
||||
only on export.
|
||||
|
||||
## References
|
||||
|
||||
- Salesforce Account object reference — https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_account.htm
|
||||
- Shellblack, Leads vs Account and Contacts — https://www.shellblack.com/whiteboard/overview-of-leads-account-and-contacts-the-salesforce-data-model/
|
||||
- SalesforceBen, Account best practices — https://www.salesforceben.com/best-practices-salesforce-account-object/
|
||||
Loading…
Add table
Add a link
Reference in a new issue