Integrate AML screening directly into your stack.
The BriteBase screening API is a self-serve delivery option for engineering-led teams: embed sanctions, PEP and adverse-media screening into onboarding, customer monitoring or payment flows, with structured responses and low implementation friction.
One call in, a structured decision back.
Real-time screening
Send a customer, company or payment and get a structured decision back in the same request, not a batch job you poll later.
One entity-resolution engine
Sanctions, PEP and adverse-media matching all run through the same resolution logic, so the noise reduction and rationale format are consistent across every check.
Structured, explainable responses
Every hit carries a plain-language rationale and a risk signal breakdown, not just a bare match score, so your team can act on the response without a second lookup.
API-key authentication
Every request is authenticated with a key issued to your account when you get access. No shared credentials, no unauthenticated endpoints.
Four steps from access to an audit-ready record.
Get API access. Book a demo or contact us and we will provision a key and walk through the integration with your team.
Send a screening request. Pass the entity you are screening, a customer, a company, or a payment party, in a structured request.
Receive a structured decision. The response carries the match outcome, a risk signal breakdown, and a plain-language rationale for any hit.
Record the disposition. Push your team’s decision back so it lives in the same audit trail as the original screening call.
Illustrative, not a full reference.
The example alongside shows the general shape of a screening call and response, an entity in, a decision with a rationale out. Exact endpoints, fields and authentication details are shared directly with your team once you have API access, so this page stays a starting point rather than out-of-date reference documentation.
- Sandbox access for integration testing before go-live
- Engineering support during integration, not a self-serve-only handoff
POST /screen
{
"entity_type": "individual",
"name": "Caspian Trade Group",
"jurisdiction": "CY",
"checks": ["sanctions", "pep", "adverse_media"]
}
200 OK
{
"result": "review",
"risk_score": 35,
"hits": [
{
"list": "pep_tier_2",
"rationale": "Name and role match against
a tier-2 politically exposed person
record.",
"disposition": "pending"
}
]
}Developer FAQ
Is the API self-serve, or do I need a sales call first?
Access is self-serve once your account is provisioned, so day-to-day integration work does not route through sales. We do ask every new integration to talk to engineering once before going live, and that call is not a commercial gate. It exists because the right request structure depends on specifics we cannot guess: which entity types you are screening, whether you are screening customers, companies or payment parties, the volume and burst pattern you expect, and whether entities should be enrolled for ongoing monitoring at the same time. Getting those decisions right at the start avoids the most common integration rework, which is discovering after launch that requests were structured for one entity type and the business needs another. After that call you receive a key, sandbox access for integration testing, and the full endpoint reference, and your team can build against it without waiting on us.
Does the API cover ongoing monitoring, or only point-in-time checks?
Both, through the same integration. A screening call at onboarding is a point-in-time check that returns a decision for that moment. Entities can also be enrolled for ongoing monitoring, so they are re-screened continuously as sanctions lists, PEP status and adverse-media coverage change, and new matches surface for disposition close to when the change occurs. This matters because a customer who cleared cleanly at signup can become a match the next day, and a point-in-time check alone would never surface that. Enrolment does not require a separate polling job on your side; you are not responsible for re-sending the customer book on a schedule. Both modes run through the same entity-resolution engine, so the false-positive reduction and the plain-language rationale attached to each hit are identical whether a match came from onboarding or from monitoring months later.
Can I use the API alongside the case-management platform?
Yes, and the two are designed to be used together rather than as alternatives. The API and the unified compliance platform share one entity-resolution engine and one underlying data layer, so an engineering team can embed screening directly into the product via the API while compliance operations works the resulting alerts, investigations and monitoring inside the platform console. Because both draw on the same engine, a decision does not change depending on which surface triggered it, and the audit trail stays continuous across both rather than splitting into two disconnected records. This split suits most regulated fintechs, where engineering owns the onboarding or payment flow that needs a screening result in-line, and compliance owns the review and disposition work that follows. The same applies to the watchlist data on its own, for teams running their own screening technology.
Get API access and a walkthrough with engineering.
Book a demo and we will provision access, share the full endpoint reference, and help you scope the integration.