The Entity 360

Core Concept

The Entity 360 is not a separate object; it is the entity viewed through everything attached to it. Retrieving an entity returns its profile and, for a business, its full ownership graph (UBOs, directors, shareholders, PSCs, with shares and designations). From the entity you traverse to its risk score, verifications, transactions, signals, activities and cases. The 360 is the composition of these reads, keyed to one identifier.

Retrieve an entity for its profile and ownership graph, then traverse to its signals, activities, transactions and cases. Each shares the entity as its anchor, so nothing needs reconciling.

• Profile: identifying data, enriched over time

• Ownership: UBOs, directors, PSCs, share %

• Verifications: every KYC/KYB/AML result

• Transactions: activity + evaluations (KYT)

• Signals & alerts: detected events to review

• Activities: immutable audit log

• Cases: investigations + AI summaries

What that looks like for a business

Retrieving a business entity returns its full ownership graph in one call. This is the first-class expression of affiliates and relationships: a subject and the people who own or control it, in one view.

"ubos": [
  { "designation": "PERSONS WITH SIGNIFICANT CONTROL", "principalOwner": true,
    "firstName": "DOE", "lastName": "JOHN", "entityId": "68752fe3...cfa" },
  { "designation": "SHAREHOLDER", "sharesCount": 9990000,
    "firstName": "DOE", "lastName": "JANE", "entityId": "68752fe4...cfc" }
]

Entity classification

Entities fall into two groups. Base Entities (Individual, Business) stand on their own. Relationship Entities (UBO, Downstream Entity) are an individual or business that relates to a parent and are mapped to it via parentId.

_Base

Individual

A natural person.

_Base

Business

A legal entity, with incorporation details and an ownership graph.

_Relationship

UBO

An owner or controller of a business, linked through a mapping with designation and share data.

_Relationship

Downstream Entity

A business or individual that belongs to a platform customer (PSP/BaaS), linked via parentId.

The platform hierarchy

A Downstream Entity is a customer of your customer. Some businesses you serve are themselves platforms (a payment processor, aggregator or BaaS) that use Cowork to protect their merchants and fintechs.

One field expresses the whole relationship: parentId. A downstream entity sets parentId to its platform; a top-level entity leaves it null. Because an entity can have both a parent and children, “platform” is a role any entity can play, and the structure nests to any depth: the processor or BaaS at the top, its merchants and fintechs as downstream entities, and a downstream fintech adding its own downstream entities in turn. Every entity keeps its own score, signals, transactions and cases, and the parentId chain lets a platform see everything beneath it. Localise the label per context (“Sub-merchant” for card/acquiring, “Partner” for BaaS) while the model name stays Downstream Entity.

List a platform's whole book with GET /v2/api/entities?parentId=ent_… · walk the chain up or down for investigations.

Worked example: PayCo → FinCo → ShopCo

A processor, PayCo, onboards a fintech, FinCo, as a Business entity with full KYB and UBOs. FinCo takes on a merchant, ShopCo, but shares only ShopCo's email, so ShopCo is added as a Downstream Entity (parentId = FinCo), thinly known but tracked. In PayCo's 360: FinCo shows full profile + ownership + UBOs, with ShopCo as a dedicated downstream entity beneath it.

Transaction attribution. FinCo's own activity (e.g. a wallet cash-out from its PayCo balance) attaches to FinCo. ShopCo's activity (e.g. a card payment or P2P) attaches to ShopCo, even though it flows through FinCo. Both appear in PayCo's rolled-up 360, segmented by entity, so signals fire against the right party.