Compliance Decisions are scored with a combination of machine learning models and rules. Scores ultimately affect decisioning. The rule engine helps provide deterministic behavior and gives you control over the system. Rules can be modified in a dashboard by risk teams without engineering support. There are out-of-the-box rules for common fraud topologies to help you get started. Rules are evaluated in real-time (e.g. hundreds of milliseconds).
A rule is comprised of a set of conditions. A rule condition is composed of a signal, an operator, and a value (e.g. flag if there are >5 email addresses linked to a given device ID). Conditions can be combined together (e.g. AND and OR logic) for creating complex rules. For a given rule, you can select what risk level to set when the rule is triggered.
If multiple rules are triggered with different risk levels, the highest risk level is selected.
There are over 1600 signals that can be leveraged to create rules for KYC, bank account validation, and transaction monitoring. The available data depends on what checks are performed. Below are some examples of the signals provided:
- Address: Number of customers or transactions associated with the address, risky countries, completeness score, validity score, how often seen across the network.
- Bank account: Closed account status, likely return status, mismatch between the bank account owner and the user's name or address, possible neobank or credit union, risky routing number, likely invalid bank account, blocklisted by network.
- Behavior: Auto-fill, copy paste, distraction or hesitation, typing speed, mouse movements.
- Device: Number of emails / phone numbers / IP addresses / fraud events associated with the device, operating system anomaly, device language, distance between the IP address and device GPS, device emulator being used, blocklisted by network.
- Email: Number of names or phone numbers associated with the email, contains the first or last name of the user, is the email verified, account or domain age, linked social media accounts, disposable or invalid domains, blocklisted by network, email reputation.
- IP address: Type of IP address, internet service provider (ISP), location mismatches between IP and device data or user's submitted address, network speed, blocklisted by network.
- Phone: Number of users or emails associated with the phone, is the phone number verified, phone type, phone carrier, date of birth match, SSN match, blocklisted by network, phone reputation.
- Tax ID: Synthetic identity score, identity theft score, abuse score, name mismatches, name match, date of birth match, number of emails or phones or IP addresses associated with the tax ID, blocklisted by network.
- Transaction: Amount, currency, higher than usual amount or frequency compared with the user's previous transactions or other users' transactions,..
- User: Number of devices associated with the user, age of the account, age of the user, number of bank accounts, transactions activity patterns, updates to name or email or phone.
- Watchlist: sanction risk, politically exposed person risk, adverse media risk, is the user on the 314a list, specific categories of offenses.
If you have additional data from other providers or internal systems, you can pass it to Modern Treasury for use in the rule engine. The User Onboarding and Payment Order objects have a
compliance_rule_metadata field for this purpose. If you add a new custom field, it can take up to a week to appear in the rule engine. At this time, custom data can be used in rules relating to KYC, bank risk, and transaction monitoring decisions, and not KYB decisions.
Functions can be used to combine different signals together for use in a condition. You can do arithmetic (e.g. add, subtract, multiply, divide), relational comparisons (greater than, greater than or equal to, less than, less than or equal to, not equals to, equals to), string similarity (e.g. Jaro-Winkler similiarity), contains (e.g. contains, not contains, contains any), prefixes / suffixes, and more.
A rule condition is composed of a signal, operator, and values (e.g. flag if there are >5 email addresses linked to a given device ID. Depending on the data type, different operators can be used:
- Array: Equal to, not equal to, in, not in.
- Boolean: Equal to, not equal to.
- Float: Equal to, not equal to, greater than, greater than or equal to, less than, less than or equal to, in, not in.
- Integer: Equal to, not equal to, greater than, greater than or equal to, less than, less than or equal to, in, not in.
- String: Equals, not equals, in, not in.
You can test rules by putting them in Shadow mode. Rules in shadow mode will still appear in API responses and the dashboard, but they will not affect scores. Statistics (e.g. fire rate, precision, recall) are computed for evaluation.
Updated 3 months ago