Assetera DocsTenancy & responsibility
One multi-tenant Marketplace API, per-tenant catalogs, and who is responsible for KYC/AML under a reliance vs a tied-agent arrangement.
Assetera serves its own investors and distribution partners' customers through one shared, multi-tenant Marketplace API. There is no per-partner deployment: every partner (and Assetera itself) is a tenant of the same service, strictly isolated from the others.
Assetera is a tenant of its own API.
How a tenant is resolved
The tenant a request belongs to is never a request parameter or header the caller can set. It is a signed claim in the caller's token, issued by Assetera Identity from the configured client and user context. The API reads it server-side and scopes every query to it.
A tenant sees only its own catalog, its own users' activity and its own audit trail. Its catalog is set by entitlement (instruments are assigned to a tenant), so two partners can be offered different subsets of the same underlying assets. (See the catalog lifecycle.)
Identity and onboarding are separate choices
| Partner model | Customer identity | Onboarding source |
|---|---|---|
| Tied agent | Customer signs up with Assetera through the partner journey. | Assetera-led MetaKYC workflow embedded by the partner. |
| DSP reliance | Existing DSP identity, federated or delegated as agreed. | DSP due diligence supplied under a written reliance agreement. |
The tenant context, human identity, and onboarding provenance remain separate records. This lets Assetera apply one tenant-isolation contract without pretending every partner has the same identity system.
Who is responsible for KYC / AML
Assetera runs the compliance layer. Assetera is the responsible party for KYC and AML. A partner operates under one of two arrangements, which change who performed the customer due diligence, not who monitors trading:
| Reliance agreement | Tied agent | |
|---|---|---|
| The partner is | a separately regulated entity | an appointed representative under Assetera's licence |
| Who did the CDD | the partner (Assetera relies on it) | Assetera (or on Assetera's behalf) |
| Ongoing regulated controls | Assetera, with partner duties defined in the agreement | Assetera, with tied-agent duties defined in the agreement |
| Regulatory responsibility | shared per the agreement | Assetera carries it |
In both cases the agreement defines responsibilities, information duties, escalation routes, and any reporting allocation. The technical integration supplies the identity and customer context needed for that model without exposing internal control rules.
Reliance does not mean "no data"
Under a reliance agreement a partner's already-verified customer can proceed without automatically repeating the same onboarding checks. Reliance is about who performed customer due diligence, not an exemption from customer identification, record keeping, eligibility, or ongoing obligations. A defined minimum still travels:
- Per partner: the agreement reference, the entity that performed CDD (with its LEI), a commitment to retrieve the underlying records on request, and the reporting role: is the partner the executing broker (they carry MiFIR reporting) or white-label (Assetera carries it)?
- Per customer: a stable identifier, due-diligence assertion and provenance, plus the customer and reporting information required by the agreed products.
- Per transaction: who/what/when/how much, plus reportable identifiers where Assetera is the executing broker.
The exact regulatory setup (reliance vs tied agent, executing-broker vs white-label, and the precise minimum data set) is fixed per partner with Assetera's Compliance team. The above is the shape of the model, not a final payload schema or legal determination.
Next
Assets and markets
How Assetera separates an issuer, a logical instrument, and the market through which that instrument is offered.
Compliance gating
How Assetera enforces eligibility at the point of action: off-chain KYC plus on-chain, single-use, signed EIP-712 attestations that authorize each trade.