The Transaction Checks API helps you to perform compliance checks on financial transactions in real time. It is designed to identify suspicious or high-risk activity by analyzing transaction details against configured rules and risk scenarios.
This API supports both new transaction checks and reprocessing of existing transactions, enabling you to streamline fraud prevention, AML/CFT compliance, and case management workflows.
Use-cases
The following are some of the most important and widely used use cases. They give you an introduction on how they are mapped for monitoring, and each one links to details and an example scenario:
Monitoring can cover screening and AML depending on configuration (also in combination).
FAQs
How do I define the account holding party in a /transaction-checks request?
In a /transaction-checks request, you must provide both a fundsBeneficiary and a fundsOriginator. Together, these define the direction of the money flow.
For most checks, it is necessary to define:
Customer → The party who holds an account with your business.
Counterparty → The party who does not hold an account with your business.
This distinction is set using the accountHoldingParty field, which can be either FUNDS_ORIGINATOR or FUNDS_BENEFICIARY.
Examples
Case 1: Your customer transfers money to someone else
"accountHoldingParty": "FUNDS_ORIGINATOR",
"fundsOriginator": {
"accountNumber": "DE12500105170648489890"
},
"fundsBeneficiary": {
"accountNumber": "DE12500105170648489890"
}
Case 2: Your customer receives money from someone else
"accountHoldingParty": "FUNDS_BENEFICIARY",
"fundsOriginator": {
"accountNumber": "DE12500105170648489890"
},
"fundsBeneficiary": {
"accountNumber": "DE12500105170648489890"
}What if both sides are customers of the bank?
In this case, transactions must be checked from both perspectives:
Your customer as the originator sending money.
Your customer as the beneficiary receiving money.
This means such transactions must be submitted twice. See the Internal Transactions page for details.
How is an account uniquely identified?
Account object
The account object, used in fundsBeneficiary, fundsOriginator, and other endpoints, provides multiple fields that can be used to uniquely identify an account.
Which fields are required depends on the use case.
Common use-cases
Use Case | Field(s) | Description | Example |
|---|---|---|---|
Bank account |
| Standard account numbers as used in national or international schemes (e.g., IBAN, ACH routing number, credit card numbers). |
|
Bank country |
| Alpha-2 country code of the account. |
|
Credit card | Combination of: | Identifies a credit card account. |
|
Online wallets |
| Some schemes (e.g., PayPal) use the user’s email address as the primary account identifier. |
|
Custom IDs / Tokens |
| Any unique identifier used in your system, such as a hash or tokenized card number. |
|
Field combination for uniqueness
By default, the system considers the combination of the following fields to uniquely identify an account within your tenant:
bankCountry + accountNumber + accountEmailId + accountId + bankIdentifier + last4Digits + expiry
If the
accountNumberqualifies as an IBAN (which is inherently unique), then only theaccountNumberis used as the unique identifier.Other fields from the account object (e.g.,
bankName,holder,productCode) are not used for unique account identification.
Can the outcome of a case change?
Yes. Case outcomes may change under certain conditions:
When transactions are sent to the respective endpoint, they are processed immediately. A successful synchronous response will return HTTP 200.
For real-time workflows (those that can block a transaction), if processing cannot be completed within the defined timeout, the API returns HTTP 202. In this case, processing will resume asynchronously usually within a few seconds.
Case results may change later due to operational reasons or user interactions. Updates are communicated via API callbacks and are visible in the Case Manager. The audit trail for each case provides exact processing times.
Because user actions can also trigger callbacks, you may receive updates long after the initial request, sometimes even weeks later. Cases may also transition into states that are not typical for the default workflow (for example, users may open months-old cases that were never opened before).