Assetera DocsDSP reliance integration
Integrate as a distribution partner using existing customer identities and due diligence under a reliance agreement.
A distribution service provider (DSP) can keep its existing users and onboarding journey. Assetera links a stable partner identity to a tenant-scoped end-client record and receives the information required by the reliance agreement.
Responsibility before transport
The reliance agreement defines who performed customer due diligence, what Assetera may rely on, which records must be supplied or retrievable, and how changes and exceptions are handled. The technical integration implements that agreement; it does not create reliance by itself.
The final customer data set is still being agreed with Compliance. The categories below are an integration checklist, not the final schema. Assetera will provide the versioned contract before implementation.
Identity options
| Option | Customer experience | Assetera identity result |
|---|---|---|
| Federated sign-in | The customer signs in with the DSP's existing OIDC or SAML identity provider. | Assetera Identity brokers the sign-in and links it to a stable Assetera subject within the DSP tenant. |
| Delegated backend | The customer remains entirely in the DSP application. | The DSP backend authenticates as a confidential client; a per-user exchange or agreed subject mapping is added where user-level authorization is required. |
Federation is configured per partner. Issuer, audience, signing keys, allowed claims, subject mapping, logout, and account-linking behavior are agreed and tested before go-live. Assetera does not accept an unsigned user identifier supplied by a browser as identity proof.
Federated reliance flow
Reliance customer record
Plan for these categories. Exact fields, formats, enumerations, evidence, and update rules will arrive in a versioned contract.
| Category | Purpose | Status |
|---|---|---|
| Partner customer key | Stable, non-recycled identifier used for reconciliation | Required in principle |
| Identity link | Federated subject or agreed delegated subject mapping | Depends on identity option |
| Customer type | Individual or legal entity | Required in principle |
| Core identifying data | Information needed to identify the end client and maintain Assetera's record | Final field list pending |
| Due-diligence assertion | Outcome, completion date, applicable level or scope, and source | Final values pending |
| Reliance provenance | Agreement and regulated entity under which the assertion is supplied | Final fields pending |
| Investor and reporting data | Information required for the agreed products and regulated role | Partner-specific |
| Evidence retrieval | How Assetera obtains underlying records when required | Agreed operationally |
| Change notification | How material customer or status changes reach Assetera | Agreed operationally |
Do not send identity documents, raw screening output, or additional personal data until the contract and approved transfer method require it. Data minimization applies even when the partner already holds a larger profile.
Acceptance and exceptions
The onboarding boundary returns a business outcome such as accepted, incomplete, or requiring review. It does not reveal Assetera's internal rules, thresholds, monitoring scenarios, or reviewer procedures. A customer record must be accepted before regulated actions are enabled.
If information is missing or inconsistent, the DSP keeps the customer in its normal journey while the agreed partner and Assetera contacts resolve the exception. Do not automatically retry permanent business rejections or silently replace one customer subject with another.
Integration requirements
- Keep client credentials, assertions, API tokens, and reliance payloads server-side.
- Use signed OIDC or SAML assertions with strict issuer, audience, signature, expiry, and replay checks.
- Preserve a deterministic mapping between the DSP customer key, federated subject, and Assetera subject.
- Make customer-record writes idempotent and retain the correlation ID returned by Assetera.
- Send only the fields allowed by the current reliance contract over the approved encrypted channel.
- Test tenant isolation, subject-mismatch, replay, stale-status, and unavailable-upstream cases before go-live.
- Maintain an operational route for evidence retrieval, corrections, status changes, and customer closure.
What remains partner-specific
Reliance contract fields pending
Add the Compliance-approved field list, JSON schema, submission endpoint, update events, and evidence retrieval service levels here when they are agreed. Until then, do not build a production payload from the category table above.
Bring your own users
Non-technical view of tied-agent and reliance models.
Partner onboarding
Provisioning, credential boundaries, and go-live sequence.
Authentication
Federation, delegated access, and tenant-scoped tokens.
Tenancy and responsibility
How identity, tenant isolation, and reliance fit together.
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.
API reference
The integrator-facing Assetera interfaces for authentication, marketplace operations, compliance status, and real-time updates.