Migrate to
/v2/customer-checks
before February 1, 2026.Support for
/v1
will officially end after this date, and all requests to/v1
will fail. To avoid service disruption, please update your systems to use/v2/customer-checks
.
The Customer checks API helps you to evaluate a customer’s AML risk profile and return a customer risk score (including risk level, risk points, risk factors), which you can reuse across your onboarding and monitoring flows. Responses received from this endpoint are displayed in the Case manager under “Customer cases”. This endpoint keeps risk scoring separate from full AML/Fraud checks, so you can call it early and often without running a full screening each time.
Use cases
Initial onboarding/KYC: score a new customer before activating the account.
Ongoing due diligence: re-check an existing customer after data changes (e.g., address or name updates).
Subsequent correlation: store the returned customer Id, so screening and transaction-monitoring decisions reference the same entity in future calls.
To achieve this, send a POST
request with customer attributes, receive risk level/score, references (customerId
,caseId, casestatus
), and timestamps. Parameters such as riskLevel
or caseStatus
should be treated as open sets. Your integration shouldn’t break if new values appear in future.
To get started use endpoint: POST /v2/customer-checks/check
FAQ
What are the possible values of caseStatus in the response?
The caseStatus
field indicates the current state of a case. Possible values are:
open: A case is open because one of the configured risks triggered it.
not-opened: No case was opened, as no configured risks were triggered.
closed: The case has been reviewed and closed.
Note: This field is dynamic. Additional values may be introduced in the future. Clients should implement caseStatus
handling in a flexible way to avoid breaking when new statuses are added.
What does the nonStrictParsingMode field mean in the response?
The nonStrictParsingMode
field can be safely ignored.
Best practice is to build your integration so that it parses only the fields it needs and ignores unknown or additional fields.
This approach ensures your integration remains stable if new fields, features, or metadata are added in the future.