Can UBO information be submitted separately from the business?

Follow-up probe to the MT failure-webhooks spike (RENTAL-594) · run 2026-07-07 against the shared Modern Treasury sandbox · raw REST, no SDK · scripts 07-ubo-probe.mjs / 08-ubo-attach-variants.mjs, wire captures under snapshots/07-ubo-probe/ and snapshots/08-ubo-attach-variants/ · card commerce#insane-dynamic-shield

Why we ran this

David asked (comment on commerce#retire-lawsuit-intact) whether UBO information can be submitted separately from the business — e.g. business first, owners later. The original spike never exercised associations, but its captures hinted "probably yes": MT models UBOs as separate legal entities linked via legal_entity_associations, the create-time completeness checklist has no beneficial-owner rule, and PATCH re-triggers verification. The probe was run to confirm before answering. The hint was wrong.

What was attempted

Every plausible API surface for attaching a UBO after the business exists:

Evidence paths are relative to snapshots/; 07/ = 07-ubo-probe, 08/ = 08-ubo-attach-variants, 09/ = 09-link-by-id-at-create, 10/ = 10-ubo-removal (a business created with two embedded owners; attempts 8–12 all ran against it). Each file holds the exact request body sent and the raw response. Attempt 7 was added after David pointed at MT's "Using existing child legal entities" guide: the individual from attempt 6 was linked at a fresh business create — association persisted (ownership_percentage: 40 round-tripped) and the business activated. Note the docs' constraint: an association takes child_legal_entity or child_legal_entity_id, never both.

The two decisive wire captures

PATCH is a silent no-op, not a rejection

Business 912a0ee8 was created with no associations and auto-activated. A PATCH carrying a complete beneficial owner (name, DOB, address, SSN, 40% ownership) returned 200 OK — and the response body still shows "legal_entity_associations": []. No updated event was ever emitted (the events log stayed [activated, created] through 30s of polling), so MT didn't just decline the field — it never registered a change at all. The same happened when linking a pre-created individual by id (attempt 3).

PATCH /api/legal_entities/912a0ee8-5d48-46ba-b2ba-39ece2354082
{ "legal_entity_associations": [ { "relationship_types": ["beneficial_owner"],
    "ownership_percentage": 40, "child_legal_entity": { ...complete individual... } } ] }

→ HTTP 200
   "legal_entity_associations": []        ← field silently dropped
   events after 30s: [activated, created] ← no "updated" ever fired

Embedded at create is the one path that works

The identical association payload, embedded in a fresh business create, persists fully: the association gets an id, the child becomes a real legal entity with its own id and pending status, and ownership_percentage round-trips.

POST /api/legal_entities   (business + embedded legal_entity_associations)

→ HTTP 201, parent 89fb5992-5647-4424-acdd-57469b9d3ae4 (status: pending)
   association 30224e62-c5c1-47eb-9a34-5d05f11066b0
     relationship_types: ["beneficial_owner"], ownership_percentage: 40
     child_legal_entity: 7fe6fe37-f26d-4cbc-9b0e-b78cb80bde24
       (type: individual, status: pending)

Corroboration against MT's docs and SDK

The sandbox probes were run first from prior API knowledge plus two guessed paths; the findings were then checked against Modern Treasury's public documentation and their official (Stainless-generated) Node SDK on 2026-07-07. Everything lines up — and adds a twist:

• MT documents the immutability outright. The Legal Entity Associations reference: "These associations cannot be created or modified directly." The Update Legal Entity OpenAPI schema contains zero occurrences of legal_entity_associations.
• The silent PATCH drop is documented behavior. legal_entity_associations is not among the accepted body parameters on the Update Legal Entity reference; MT drops unaccepted params rather than rejecting them. It was never updatable.
• The standalone endpoint used to exist — MT removed it recently. The Node SDK shipped legalEntityAssociations.create() against exactly POST /api/legal_entity_associations from Feb 2024 (modern-treasury-node commit 7e5b2983). Bisecting the SDK's history shows the method was removed from the OpenAPI spec between 2026-03-25 and 2026-04-06; today the resource class is empty and the "Create Legal Entity Association" docs page returns a real 404 (Google still indexes it). Our sandbox 404 is the removal, not an access or version issue.
• The replacement is still create-time. MT's 2026-04-10 changelog entry lets an existing individual be reused as a beneficial owner by passing its legal entity id in the business create request — no post-create path.

Method notes

• Same harness as the parent spike: raw fetch against app.moderntreasury.com (no SDK, so error bodies and silent drops are seen exactly as the wire delivers them), creds from apps/api/.env, every request/response pair snapshotted to JSON.
• Create-only: five new entities, all named SPIKE RENTAL-594 …, fresh EINs to dodge MT's dedupe. No ledger/book objects touched.
• Business creates used the full completeness payload the parent spike established (address, EIN, date formed, intended use, activity volume, proof-of-address document) so a 422 could never mask the association behavior.
• Attempt 3 controls for "maybe the child must exist first": the individual was created standalone (201) before the link-by-id PATCH — the PATCH still dropped it.

What this means for us

• The onboarding packet is atomic: business + all UBOs must be assembled before the single MT create. This reinforces the earlier finding that the stepped/partial experience has to live in Commerce (our requirements model), with MT receiving one complete submission.
• Late UBOs mean re-create: there is no amendment path. A new entity must be created with the associations embedded, and since MT enforces EIN dedupe, the old entity has to be discarded first.
• Softener: our compliance profile does not require UBOs — the create-time completeness checklist has no beneficial-owner rule, and association-less businesses activate in sandbox.

File inventory