Partner onboarding
The path to a live Assetera distribution tenant: your identity client, choosing an integration mode, the walkthrough, KYC reliance, and go-live.
Onboarding a distribution partner is done by configuration, not by writing partner-specific code. A new partner becomes a tenant of the shared Marketplace API: a config row plus an identity client, not a new deployment. This page walks the path at a high level.
Provisioning is not self-serve yet. There is no signup form or partner console today; the exact steps (creating your identity client, agreeing your reliance and reporting setup, enabling instruments) are handled together with the Assetera team. This page describes what happens, so you can prepare.
The onboarding path
-
An identity client is provisioned for your tenant. Assetera creates a confidential OIDC client bound to your tenant. Every token that client obtains carries a signed
tenantclaim; the Marketplace API reads that claim server-side and scopes all of your data to it. Partner clients are OAuth2 confidential clients (never raw API keys), so credentials are short-lived, rotatable and auditable. Where possible the client usesprivate_key_jwt(you hold the private key; Assetera registers only your public keys), so no shared secret crosses the boundary. -
You choose an integration mode. Either the Assetera-hosted UI for a turnkey path, or your own frontend/backend. See Integrating with Assetera for the trade-offs. The mode changes only how your tokens are obtained; the token contract and the API are the same either way.
-
If you build your own UI, follow the walkthrough. The tied-agent walkthrough is the reference Backend-for-Frontend pattern. Its one non-negotiable rule: the browser never receives an access token. Tokens stay server-side in your BFF's session store, and the browser holds only an opaque HttpOnly cookie. The UI may role-gate for user experience, but authorization is enforced by the API and Assetera Identity, then re-checked, never moved into the frontend.
-
You agree your reliance and reporting setup. Under a KYC-reliance agreement, your already-verified customers can transact without Assetera re-running KYC, but reliance is about who performed CDD, not who monitors transactions. Assetera stays responsible for transaction monitoring and, where it is the executing broker, MiFIR reporting. So a defined minimum of data still travels per partner (agreement reference plus the relied entity's LEI, CDD-retrieval commitment, reporting role) and per customer (a stable identifier, KYC status/level, investor category, wallet addresses).
Reliance narrows the onboarding data; it does not zero it out. Whether Assetera is the executing broker or a white-label distributor is a Compliance decision per partner, and it determines which reportable identifiers must be collected at trade time.
-
You run the go-live checklist. Before switching a tenant to
active:- Identity client provisioned; token flow verified for your chosen mode.
tenantclaim present and correct on issued tokens; audience/scopes match the API you call.- Instrument entitlements set: which token pairs your tenant may offer.
- Reliance agreement recorded (or
self_onboardchosen); reporting role fixed with Compliance. - If self-hosting a UI, the BFF browser-holds-no-token rule verified end-to-end.
Where to go next
KYC integration (MetaKYC SDK)
Embed Assetera's KYC flow with the @asseteragmbh/metakyc React SDK. Create a session token on your server, then render the workflow in your app.
DSP integration
How a distribution service provider integrates once to distribute many issuers' tokenized assets across chains through Assetera's APIs.