Relying Party Onboarding & Launch Process

📹 Watch video walkthrough

In Trinsic, each of your customers is a relying party. A relying party holds everything that’s specific to that customer: their branding, their domains, and their provider registrations. You set it up once, and every verification profile you create for that customer reuses it.

01 — Initial alignment and requirements

Before any configuration begins, you and Trinsic will align on the key details that drive the implementation path.

• Which providers are being prioritized for launch
• Whether attribute-specific verification is required
• Data minimization or scoped attribute requirements
• Which geographies the customer needs, and any data residency requirements (US, EU)
• Expected transaction volume (initial and steady-state)
• Target timeline and launch milestones

02 — Create the relying party

Create a relying party for your customer in the Relying Parties tab. This becomes the home base for their onboarding.

• Name it after your customer
• Include their branding and any custom domains. For production, we recommend a custom domain for consistent branding and end-user trust.
• Add an external ID if you want to sync it with your own systems

03 — Request providers and collect registration details

On the relying party, request the providers your customer wants to launch with. Many providers need registration details before they can be activated, such as legal entity information, the use case, and brand assets.

1. Complete each provider’s registration form yourself, or share the forms with your customer through the same link
2. Use the registration guide on each provider to see what’s needed
3. Request at least one provider, then publish the relying party

05 — Legal and scheme-level activation

Some providers require additional steps beyond registration. This is often the critical path for production launch.

• Scheme-level licensing or contractual requirements
• RP eligibility constraints (industry, geography, or wallet restrictions)
• Any direct registration processes required by the provider

Until a provider is activated for your customer’s relying party, its flow uses Trinsic’s branding where available.

06 — Production verification profile setup

With the relying party in place, create a production verification profile for your customer’s use case. This step is quick because branding, domains, and registrations already live on the relying party.

1. Select the customer’s relying party
2. Choose the geography (US or EU)
3. Enable the providers for this use case
4. Set attribute scope if applicable

If your customer needs more than one use case, such as US and EU, or age and full identity verification, create a separate profile for each. They all share the same relying party.

07 — Testing plan

Before enabling production traffic, establish a structured testing plan.

1. Environment scope (sandbox vs production)
2. Availability of test credentials or testers via the Testing Network
3. Validation criteria for success and failure cases
4. Fallback flows (e.g. document verification where applicable)

08 — Final adjustments

Based on testing results, make any final updates before go-live.

• Provider configuration changes
• Attribute scoping adjustments
• UX refinements in selection or fallback flows
• Confirmation of production readiness across environments