Compliance Framework
Here is how the building blocks of our Rule Builder integrate:
A Rule is the compliance evaluation part of a Policy. When combined with user information, it can be evaluated to provide a boolean value (true or false).
A Rule is a recursive structure, which means a Rule can be composed of children Rules. Because all parts of the Rule structure are independent, we can represent a Rule as a Tree structure.
Rules fall into two categories: Base Rules and Composite Rules.
Base Rules
Definition: Base Rules are the foundational building blocks of the Rule Builder. They are the final nodes (or leaves) of a Rule Tree, that can be individually evaluated. Each of them includes a data point, its value, and the validation process (where is the data coming from, who checked it).
Example: A simplified version would be country of incorporation == GB, as verified by ShuftiPro.
Application: Keyring codes all checks that can be performed by external Compliance Partners, and links them to Base Rules. Keyring is responsible for maintaining the Rule Registry.
Composite Rules
Definition: Composite Rules combine Base Rules into logical blocks. They are intermediary nodes of a Rule Tree, that have one or more child Rules called Operands, and combine them with a logical Operator (intersection, union, complement). They can be used to construct intricate checks or logic-based decision frameworks. A Policy will usually have a Standard Composite Rule as its top-level reference.
Example: a KYC Rule could be constructed as the intersection of two Base Rules: {valid proof of address == true, as verified by ComplyCube ; valid proof of identity == true, as verified by ComplyCube}.
Application: Policy Owners can combine Base Rules to create custom Composite Rules, allowing for nuanced and thorough compliance assessments.
Admission Policy
Admission Policies outline the comprehensive parameters of the permissioning implementation.
Definition: A Policy is defined by a unique immutable ID and administered by the Policy Owner. It contains:
A Top Rule, combining all sub-rules logic into one set of Rules users have to verify.
A Refresh Rate, specifying the period of validity before results have to be refreshed.
A Grace Period, setting the time buffer before changes to the Policy become effective.
A list of , running the verification compute.
A list of whitelisted contracts (Policy Whitelist), and a toggle allowing users to maintain their own whitelist (User Whitelist).
Regulatory backdoors, specifying the conditions for de-anonymisation (more here).
Failsafe mechanisms, detailing recovery procedures in case of service failure.
Example: Specific implementations can be explored in the .
Application: Any Keyring Client can become a Policy Owner. Users and other clients who rely on Admission Policies can inspect its parameters on the Keyring App. One key aspect of Admission Policies is that they are upgradeable so Policy Owners can meet evolving regulatory requirements and adapt to new risk factors.
Last updated
