Customer checks

Prev Next

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.