> ## Documentation Index
> Fetch the complete documentation index at: https://docs.frankieone.com/llms.txt
> Use this file to discover all available pages before exploring further.
# A Detailed Guide to eKYC Rulesets
An in-depth guide to how FrankieOne’s KYC rulesets power your verification workflows and help you meet regional compliance requirements.
## What is a KYC Ruleset?
> *A KYC Ruleset is the engine that drives a verification decision within a FrankieOne workflow.*
> *It’s a pre-configured set of logical conditions that defines exactly what is required for a customer’s identity to be considered verified.*
When you execute a KYC workflow, the ruleset is applied to the customer’s data. The workflow checks this data against various independent sources (like credit bureaus or government databases), and the ruleset determines if the returned matches are sufficient to meet your specific compliance and business needs.
FrankieOne provides standard, out-of-the-box rulesets designed to meet common regulatory requirements in different regions, such as **Australia’s 2+2 verification** or **Canada’s FINTRAC methods**.
***
## How Rulesets Work
At its core, a ruleset is based on two simple principles:
* **name** : The customer’s full name.
* **dob** : The customer’s date of birth.
* **address** : The customer’s residential address.
* **gov\_id** : A government-issued document like a passport or driver’s licence.
For each piece of information, the ruleset defines the **minimum number of successful matches** required from independent data sources.\
*Example: A rule might require that the customer’s name be successfully matched against at least**two** different sources.*
By combining these conditions, rulesets can accommodate a wide range of verification scenarios — from simple identity checks to complex, multi-source regulatory requirements — ensuring workflows remain flexible and compliant.
***
## Standard Ruleset Library
Below is a detailed breakdown of the common rulesets you’ll encounter when using FrankieOne’s standard workflows.
***
### 1. Australia: `two_plus` (Standard 2+2)
> ***Purpose:** Meets AML/CTF compliance in Australia.*
* **What it does:** Verifies an individual’s identity by matching their information against at least two independent data sources. As part of the upcoming changes to AML/CTF regulation, this ‘safe harbour’ model is being phased out in favour of a risk-based approach which will also be open to biometrics and digital IDs. These changes are expected for existing entities by **31st March 2026**.
* **Logic:** Requires **2× Name Matches** **AND** a combined total of **2× Address/DOB Matches**.
Australia’s AML/CTF regulations are evolving toward a risk-based approach and now recognize biometrics and digital IDs as valid verification methods. For details on upcoming changes—affecting existing entities from 31 March 2026 and new regulated entities from July 2026—refer to AUSTRAC’s official guidance.
#### Passing Combinations
| Combination | Name Matches | Address Matches | DOB Matches |
| :---------- | :----------- | :-------------- | :---------- |
| **1** | 2 | 2 | 0 |
| **2** | 2 | 0 | 2 |
| **3** | 2 | 1 | 1 |
***
### 2. Australia: `two_plus_gov_id` (2+2 with Gov ID)
> ***Purpose:** Higher-assurance variant of 2+2, mandates successful verification of a Government ID.*
* **What it does:** Increases confidence by tying the electronic verification to a physical document.
* **Logic:** Requires **2× Name Matches** **AND** **1× Gov ID Match** **AND** a combined total of **2× Address/DOB Matches**.
#### Passing Combinations
| Combination | Name Matches | Address Matches | DOB Matches | Gov ID Matches |
| :---------- | :----------- | :-------------- | :---------- | :------------- |
| **1** | 2 | 2 | 0 | 1 |
| **2** | 2 | 0 | 2 | 1 |
| **3** | 2 | 1 | 1 | 1 |
***
### 3. International: `one_plus` (Standard 1+1)
> ***Purpose:** Flexible ruleset for global use cases where a single-source verification is sufficient.*
* **What it does:** Verifies an individual’s identity against at least one reliable data source.
* **Logic:** Requires **1× Name Match** **AND** **1× Address or DOB Match**.
#### Passing Combinations
| Combination | Name Matches | Address Matches | DOB Matches |
| :---------- | :----------- | :-------------- | :---------- |
| **1** | 1 | 1 | 0 |
| **2** | 1 | 0 | 1 |
***
### 4. Document-centric: `gov_id_only`
> ***Purpose:** Relies solely on the verification of a government-issued document against an authoritative source.*
* **What it does:** Confirms the authenticity of a provided ID document quickly.
* **Logic:** Requires **1× Name Match** , **1× DOB Match** , **AND** **1× Gov ID Match** from the same document verification source.
#### Passing Combinations
| Combination | Name Matches | DOB Matches | Gov ID Matches |
| :---------- | :----------- | :---------- | :------------- |
| **1** | 1 | 1 | 1 |
***
### 5. Flexible Onboarding: `gov_id_with_alternative`
> ***Purpose:** Prioritizes Government ID verification but provides the standard “2+2” check as a fallback.*
* **What it does:** Optimizes conversion rates by providing two compliant pathways for verification in a single workflow.
* **Logic:** Passes if **EITHER** of these conditions are met:
* **Path A:** 1× Gov ID Match.
* **OR**
* **Path B:** 2× Name Matches **AND** 2× Address/DOB Matches.
#### Passing Combinations
| Part | Name Matches | Address Matches | DOB Matches | Gov ID Matches |
| :---- | :----------- | :-------------- | :---------- | :------------- |
| **A** | 1 | - | 1 | 1 |
| **B** | 2 | 2 | 0 | - |
| **B** | 2 | 0 | 2 | - |
| **B** | 2 | 1 | 1 | - |
***
### 6. High Assurance: `safe_harbour_gov_id`
> ***Purpose:** High-assurance ruleset for the strictest compliance needs, mandating multiple government ID verifications.*
* **What it does:** Offers the highest level of assurance outside of a full biometric check by requiring two separate document verifications.
* **Logic:** Requires **2× Name Matches** , **2× Gov ID Matches** , **AND** **2× Address/DOB Matches**.
#### Passing Combinations
| Combination | Name Matches | Address Matches | DOB Matches | Gov ID Matches |
| :---------- | :----------- | :-------------- | :---------- | :------------- |
| **1** | 2 | 2 | 0 | 2 |
| **2** | 2 | 0 | 2 | 2 |
| **3** | 2 | 1 | 1 | 2 |
***
### 7. International: `one_plus_gov_id` (1+1 with Gov ID)
> ***Purpose:** “1+1” ruleset that mandates the inclusion of a Government ID verification.*
* **What it does:** Combines the assurance of a document check with the breadth of an electronic data source check.
* **Logic:** Requires **1× Name Match** , **1× Gov ID Match** , **AND** **1× Address or DOB Match**.
#### Passing Combinations
| Combination | Name Matches | Address Matches | DOB Matches | Gov ID Matches |
| :---------- | :----------- | :-------------- | :---------- | :------------- |
| **1** | 1 | 1 | 0 | 1 |
| **2** | 1 | 0 | 1 | 1 |
***
### 8. Digital Services: `one_plus_dob_gov_id`
> ***Purpose:** Requires Name, DOB, and a Government ID, with no address component.*
* **What it does:** Focuses on verifying core identity (name, age) via a government document without the potential failure point of an address mismatch.
* **Logic:** Requires **1× Name Match** , **1× DOB Match** , **AND** **1× Gov ID Match**.
#### Passing Combinations
| Combination | Name Matches | DOB Matches | Gov ID Matches |
| :---------- | :----------- | :---------- | :------------- |
| **1** | 1 | 1 | 1 |
***
### 9. Age-Restricted Services: `two_plus_age`
> ***Purpose:** Specialized ruleset to verify an individual’s age with high confidence.*
* **What it does:** Allows businesses to confidently verify a user is over a certain age. The “OR” logic provides flexibility to increase pass rates.
* **Logic:** Passes if **EITHER** of these conditions are met:
* **Path A:** 2× Name Matches **AND** 2× DOB Matches.
* **OR**
* **Path B:** 2× Name Matches **AND** 1× DOB Match **AND** 1× Address Match.
**Best Practice for Age Verification:** Government-issued IDs are the most reliable data source for age verification as they provide an exact match against official records. When using consumer or commercial data sources, it is critical to review fuzziness settings to ensure they are set to require an exact match for the Date of Birth to avoid false negatives.
#### Passing Combinations
| Part | Name Matches | Address Matches | DOB Matches |
| :---- | :----------- | :-------------- | :---------- |
| **A** | 2 | 0 | 2 |
| **B** | 2 | 1 | 1 |
***
### 10a. Address-centric: `two_plus_address`
> ***Purpose:** Specialized ruleset to verify an individual’s address with high confidence.*
* **What it does:** Helps meet Proof of Address (POA) requirements by ensuring an address match is always part of a successful verification.
* **Logic:** Passes if **EITHER** of these conditions are met:
* **Path A:** 2× Name Matches **AND** 1× DOB Match **AND** 1× Address Match.
* **OR**
* **Path B:** 2× Name Matches **AND** 2× Address Matches.
#### Passing Combinations
| Part | Name Matches | Address Matches | DOB Matches |
| :---- | :----------- | :-------------- | :---------- |
| **A** | 2 | 1 | 1 |
| **B** | 2 | 2 | 0 |
### 10b. Address-centric: one\_plus\_address
Purpose: International use case requiring name and address verification against a single data source, where address confirmation is mandatory.
What it does: Verifies an individual's identity by matching their name and current address against at least one independent data source. Unlike the standard one\_plus ruleset — which accepts either an address or a date of birth as the secondary match — this variant specifically mandates a successful address match. A DOB match alone is not sufficient to pass.
Logic: Requires 1× Name Match AND 1× Address Match.
#### Passing Combinations
| Part | Name Matches | Address Matches | DOB Matches |
| :---- | :----------- | :-------------- | :---------- |
| **A** | 1 | 1 | 1 |
| **B** | 1 | 1 | 0 |
***
### 11. USA: `us_onboarding`
> ***Purpose:** Standard ruleset for US-based onboarding that aligns with common Customer Identification Program (CIP) requirements.*
* **What it does:** Provides a clear pathway to meeting baseline US federal requirements for customer identity verification under the Bank Secrecy Act (BSA).
* **Logic:** Requires **1× Name Match** , **1× DOB Match** , **1× Address Match** , **AND** **1× Gov ID Match** (e.g., an SSN).
#### Passing Combinations
| Combination | Name Matches | DOB Matches | Address Matches | Gov ID Matches |
| :---------- | :----------- | :---------- | :-------------- | :------------- |
| **1** | 1 | 1 | 1 | 1 |
***
### 12. Canada: `ca_fintrac`
> ***Purpose:** Multi-part ruleset designed to meet Canadian compliance requirements. Provides two distinct pathways for verification; a customer only needs to pass **one**.*
* **What it does:** Verifies identity using one of the methods prescribed by the Financial Transactions and Reports Analysis Centre of Canada (FINTRAC).
#### Method 1: The Credit File Method
> *Most common method. Requires matching the customer’s full name, date of birth, and address against a Canadian credit file.*
| Name Matches | DOB Matches | Address Matches | Source Requirement |
| :----------- | :---------- | :-------------- | :------------------------------------------------------- |
| 1 | 1 | 1 | All must come from a single Canadian Credit Bureau file. |
#### Method 2: The Dual Process Method
> *Alternative if the customer doesn’t have a credit file. Involves matching their information against two different, reliable sources.*
| Name Matches | DOB Matches | Address Matches | Source Requirement |
| :----------- | :---------- | :-------------- | :------------------------------------------------------- |
| 2 | 2 | 2 | Must be from two different and independent data sources. |
***
## Next Steps
Now that you understand the logic behind our rulesets, see our\
**[Electronic KYC with Government ID](/docs/electronic-kyc-checks)** guide for a step-by-step walkthrough of how to execute a workflow that uses one of these rulesets.