Tied agent or reliance partner
The two ways a partner brings its customers to Assetera, what each customer experiences under each, and where the choice is decided. Your licence position decides it.
Your licence position decides the model. No investment-services licence: you are a tied agent under Assetera's. Regulated and already verifying these customers: you are a reliance partner. In both, you keep the relationship, the brand and the UI, and Assetera runs the compliance layer.
Who is responsible for what under each model, and the minimum data that travels, is on Tenancy and responsibility. This page is the choice and the customer experience.
Two partner models
| Tied agent | Distribution partner with reliance agreement | |
|---|---|---|
| Best fit | You want Assetera to perform customer onboarding within your experience. | You already operate a regulated onboarding process that Assetera may rely on. |
| Customer account | The customer receives an Assetera identity through your sign-up journey. | The customer can use your existing identity, including federated sign-in where agreed. |
| Customer due diligence | Assetera performs the agreed onboarding flow. | You perform due diligence and provide the agreed customer information and evidence. |
| Wallet | The customer may use the embedded Assetera wallet or an eligible external wallet. | Wallet availability is agreed as part of the integration. |
| Your frontend | Remains under your brand. | Remains under your brand. |
Tied agent: Assetera-led onboarding in your product
Your customer signs up with Assetera from your application, then completes the Assetera onboarding journey inside your frontend. The same customer identity connects later services, including the embedded wallet, without asking the customer to create unrelated accounts for each service.
You control the surrounding experience, copy, and navigation. Assetera remains responsible for the regulated onboarding process and for deciding when regulated capabilities become available.
Reliance agreement: bring customers you already know
A reliance agreement can reduce repeated onboarding for customers you have already verified. You provide the customer information, status, provenance, and supporting records agreed with Assetera. Assetera creates the records it needs to provide its services and can request underlying evidence where the agreement or law requires it.
Reliance does not mean anonymous access or a zero-data integration. The exact information set, update obligations, record-retrieval process, and allocation of responsibilities are agreed before technical onboarding.
What customers experience
Sign in through the partner journey. Depending on the model, this creates an Assetera identity or connects an existing partner identity.
Complete only the onboarding steps required for the agreed model. A tied-agent customer follows the Assetera-led flow. A reliance customer normally does not repeat checks already covered by the agreement.
Choose a wallet where enabled. The embedded Assetera wallet uses the same signed-in identity. An external wallet can also be connected where supported.
Use the partner catalog. Available instruments and actions are scoped to the partner and the customer's current eligibility.
Assetera applies regulatory controls throughout the relationship. Public documentation describes the required outcomes and integration boundaries, but does not publish internal detection rules, thresholds, review procedures, or monitoring logic.
Start a partner integration
The model is fixed first. Assetera then provisions your tenant and credentials and confirms the identity route.
Offer the catalog to your customers
Give your customers Assetera's tokenized securities inside your own product. Two ways to bring users, three ways to deliver it, and what to have ready for the first call.
DSP reliance integration
Integrate as a distribution partner using existing customer identities and due diligence under a reliance agreement.