Policy Setup

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:

Keyring Pro: API connections

• 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.

Keyring Connect: MPC-TLS connections

• Users onboarding via reusing information from third-party sources. Users can add themselves to an allowlist in 3 clicks by porting their verified data from centralised exchanges or any https-enabled website supported by Keyring.

Keyring can connect to any backend server that delivers data via TLS (the “s” in HTTPS). We translate available data into standardised data attributes that can be used for authorisation purposes. MPC-TLS solves the hard problem of data authentication (how do I know the source of information is valid) by “notarising” a user’s web session to extract select information.

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. Define the Rule

Rule-setting: Keyring ProRule-setting: Keyring Connect

---

3. Set other parameters

Define refresh frequency

Static KYC/KYB information typically requires a refresh every 1 to 3 years.

Variable information such as AML and Wallet checks need to be refreshed more frequently. It corresponds to the Policy's and typically varies from 24 hours to a year. 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 (Pro).

• A user request to generate an updated validation via the Keyring extension (Connect).

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.