The Screening API uses internal blacklists to enhance match detection during entity and wallet analysis. The blacklist system in Rillis is used to enhance the detection of high-risk individuals, companies, and wallets during screening operations. It acts as a custom layer of control, allowing you to flag specific entities based on your internal policies, past fraud cases, or compliance requirements. These blacklists include:Internal watchlists maintained by your organization
Custom blacklists with known risky users, companies, or wallets
π― What Is It For?#
Automatically flag known risky entities (e.g., fraudsters, blocked clients, exposed wallets).
Prevent repeated onboarding or transaction approvals involving high-risk matches.
Maintain an internal memory of users/companies/wallets that your organization considers risky
π Blacklist Endpoints#
| Endpoint | Method | Description |
|---|
/black-list-api | POST | Create a new blacklist record. You can register wallets, individuals, or companies to flag for review. |
/black-list-api | GET | Retrieve all configured blacklist records along with their status and key parameters. |
/black-list-api/{id} | PATCH | Update the status or data of an existing blacklist record by ID. |
/black-list-api/{id} | DELETE | Permanently delete a blacklist record by ID. |
/black-list-api/{id} | GET | Fetch the full details of a specific blacklist entry by ID. |
/black-list-api/settings | PATCH | Update global blacklist settings that affect how matches are handled across the account. |
π§ How It Works#
Rillis performs blacklist matching by comparing the input data of an entity against the internal blacklist configured in Rillis, which belongs to your organization.The matching process is based on key identifying attributes, such as:
π Matching Logic#
An entity can have multiple blacklist matches.Each match is evaluated using a match percentage score ranging from 0 to 100, which represents how closely the input data matches a blacklist entry.The overall risk level of the screening analysis is determined based on the highest or most relevant match_percentage.A low percentage may be considered informational.A high percentage (e.g. 85%+) may indicate a strong match and higher risk.
π Results and Storage#
All detected blacklist matches are returned and stored in the analysis record under the following property blacklistMatches. This array contains:The matched blacklist entries
Their corresponding match_percentage
Additional metadata related to the match
These results are always available for later review through the screening records and can be used for auditing, alerts, or decision-making logic. Modified atΒ 2025-12-15 20:01:04