Assetera DocsPartner onboarding
The technical handover for an Assetera tenant: partnership model, identity, credentials, customer onboarding, and go-live evidence.
Partner onboarding starts with the legal and customer-due-diligence model, then produces a tenant-specific technical pack. Provisioning is coordinated with Assetera rather than performed through public dynamic client registration.
What Assetera needs from you
| Area | You provide |
|---|---|
| Partnership | Tied-agent or reliance-agreement route, contracting entity, technical and compliance contacts |
| Application | Redirect URIs, web origins, logout destinations, and environments |
| Identity | Native Assetera sign-up, OIDC federation, SAML federation, or delegated backend flow |
| Security | Credential recipient, secret-storage method, rotation contact, and incident contact |
| Catalog | Instruments and customer journey you intend to expose |
| Reliance only | Agreed customer data transfer, status updates, evidence retrieval, and exception process |
What Assetera provisions
Tenant and identity client. You receive an OIDC client ID and either a client secret or an agreed asymmetric client-authentication setup. Redirects, audiences, roles, and the signed tenant context are configured by Assetera.
Tied-agent onboarding credentials. Where Assetera performs customer onboarding, you receive the MetaKYC client and server-side keys required to mint short-lived SDK sessions.
Wallet configuration. Where the embedded Assetera wallet is enabled, Assetera configures the wallet environment and the Keycloak token-exchange audience. Public wallet configuration can reach the browser; OAuth and SDK secrets cannot.
API and catalog entitlements. Your client is permitted to call only the agreed audiences, and your tenant receives only the agreed instruments and operations.
Credential boundaries
| Credential or value | Where it belongs | May reach the browser? |
|---|---|---|
| OIDC client secret or private key | Partner backend or BFF secret store | No |
| MetaKYC API and secret keys | Partner backend or BFF secret store | No |
| Assetera API access and refresh tokens | Server-side session store | No |
| Opaque partner session cookie | Browser, HttpOnly, Secure, appropriate SameSite | Yes |
| MetaKYC SDK session token | Browser only for the scoped onboarding session | Yes |
| Wallet-audience token | Browser only for the embedded-wallet sign-in | Yes |
| Public wallet environment ID | Runtime frontend configuration | Yes |
The two browser-visible tokens are short-lived and purpose-restricted. Neither is a general Marketplace or Compliance API bearer token.
Go-live sequence
Before production enablement, verify at minimum:
- Redirect and origin allowlists match the production application.
- Secrets are isolated by environment, stored server-side, and have named rotation owners.
- A tied-agent user keeps the same Keycloak
subacross MetaKYC, wallet, and API calls. - A reliance user is linked deterministically to the agreed partner subject and customer record.
- Tenant and instrument isolation tests pass for both positive and negative cases.
- Session logout, revocation, retry, and unavailable-upstream behavior have been tested.
- Compliance and technical contacts can retrieve the agreed evidence and audit trail.
Assetera confirms final claim names, audiences, roles, workflow keys, and reliance fields in the tenant handover. Do not infer production values from examples or another tenant.
Tied-agent walkthrough
Use one customer subject across sign-up, KYC, wallet, and APIs.
DSP reliance integration
Federated identity and customer-record handover under reliance.
Environment and credentials
Reference configuration and secret boundaries.
Authentication
OIDC flows, user sessions, tenant context, and wallet token exchange.
Off-chain sale (bank transfer)
Create a bank-transfer primary-sale purchase, show the returned payment instruction, and track reconciliation and delivery.
Environment and credentials
The full set of environment variables a tied-agent app needs, grouped by concern, plus how each credential is issued and why nothing is hardcoded.