Policy Setup

Define the Rule

Onboarding Process: Step-by-Step

1. Choose data sources

Keyring can support any type of check as long as it is connected to the right data source, off-chain or on-chain. Our clients can choose between:

• Users onboarding through their own compliance desk. Keyring connects to their backend via API, with customisable granularity on data access. Keyring can also leverage data from on-chain whitelists.

• We have set up Master Service Agreements with our Compliance Partners, who are responsible for reviewing the information and performing the necessary checks set out by the Policy, under the Policy Owner's control. We currently support KYC, KYB, AML, KYW checks as well as custom checks, such as Accredited Investor forms.

An Admission Policy can combine different data sources to offer comprehensive onboarding flows. For instance, a Policy could accept keyring_onboarding or wallet_whitelist.

2. Set onboarding programme

The due diligence required to meet regulatory standards varies by jurisdiction, activity, and user type. We recognize the need for modular compliance and aim to provide tools to streamline processes and overcome complexities, instead of a one-size-fits-all approach. With Keyring, a Policy Owner can define logical frameworks that differentiate user onboarding flows based on the risk assessed each step of the way. This minimises total onboarding time for both the user and the compliance team.

Here is how it works: based on the information completed by the user, the relevant onboarding flow will automatically be presented, with Enhanced Due Diligence questions as required.

3. AML checks

The information provided by the user is used to run AML checks. Typically, the user will be screened against global data sources for sanction/warning lists, adverse media, PEPs and other usual risks.

4. Verification process

All information collected is securely forwarded to Keyring’s Compliance Partner(s) to be processed by their internal systems, and for human-assisted review when relevant. Users are identified to produce a unique match against publicly available lists, documents are verified, and potential AML hits are reviewed.

A Compliance Officer can liaise directly with users to request further information via a Keyring-supported instance of Zendesk.

5. Outcome

The clean, structured data is called from Compliance Partners’ backend and fed into the Policy’s Risk Matrix, crafted by the Policy Owner using Keyring’s toolbox. The Policy Rule Outcome is a binary {pass,fail} result according to the requirements defined by the Admission Policy. The user can check the status of their onboarding on the Keyring UI and can also be notified via email.

6. Dispute mechanism

Should a user fail onboarding, they will be able to dispute the decision using Zendesk.

---

Other compliance parameters

Define refresh frequency

Keyring provides the tools to set different validity periods for:

• Static KYC/KYB information: Typically 1 to 3 years.

• Variable AML and Wallet checks: Typically from 24 hours to a month, it corresponds to the Policy's .

The refresh rate is essential to keep the proofs used on the network up to date. Following the expiry of a Credential, a user will request a refresh which triggers API calls to the updated AML and KYW screening results from Compliance Partners. A Credential refresh is almost instantaneous. If the result comes back as fail, the user won't be able to refresh their Credentials.

Set Wallet Checks

The Policy Owner can elect to run checks on wallets on top of the off-chain compliance process to determine the user's eligibility. The risk assessment for on-chain activity remains independent from the first part of the process to ensure privacy remains intact. They can customise the risk scoring framework and the overall result will also be a binary {pass,fail}.

To be considered valid, a User must have both valid Credentials and a valid Wallet Check.