Transaction monitoring

What should we do if we don't have a checked applicant to add a transaction to it?

If want to create a transaction for a user that has not passed verification via our service yet, you can create a new applicant and add a transaction to it using a single request POST /resources/applicants/-/kyt/txns/-/data?levelName={levelName}.

For more information, see the Process transaction for existing applicant and Process transaction for non-existing applicant methods.

What happens to a transaction when it is added?

It is saved and then scored. Depending on the matched rules, the transaction may end up in any of the following statuses:

  • Approved
  • Rejected
  • On hold

Also, it may affect an applicant by requesting additional verifications.

How can I apply different rules to transactions from different sources?

Provide the sourceKey field in the transaction data when creating it. Rules without a source key, or source keys
that include the transaction source key will be applied.

How can I get notified about the scoring result?

You can set up webhooks the same way you do for applicants. You can react on Approved, Rejected, and On hold transactions.

How can I test a new rule without fear of breaking anything?

When installing a rule, it is in the Dry run mode by default, meaning that it will be applied, but will not affect
the final scoring. Additionally, on the Rules tab, you can test the rule by applying it to existing transactions accordingly.

What do I do with transactions that are put on hold?

You can explore them at Queues tab and make a final decision. Or you may decide to request an additional applicant action that you set up in advance, e.g. a liveness check, source of funds request, or a questionnaire.

So when the applicant action is complete, the status of the transaction will change accordingly. Thus, you can automate risky or suspicious transactions.

What if I want to have rules that are based on some custom data that are not in your data model?

Add custom fields into the props map in the transaction data. We will be able to set up rules based on them.

What can I base my rules on?

Pretty much on everything that we collected about the applicant or transaction. For example, applicant data, id docs, questionnaires, aggregations of data based on devices, geolocation, transaction amounts, and so on.

If you miss anything, get in touch. In most cases, it would be an easy exercise to add it for you.

Can I control certain transactions that match certain rules?

You can set up a custom queue based on rules and computed transaction status. Then you can review transactions that appear in such custom queues, take immediate actions, assign them to yourself or other colleagues for further investigation or confirm the resulting status (if it was approved or rejected).

What do I need to pass to stay protected?

In general, as much information as you can map to our data structure, plus put the rest into custom properties if you
think this field is important. Even if you do not have rules that work on certain fields, you may have some in the future. Then you can do a re-scoring in case you decide to add more rules.

What kind of reporting do you have?

You can get the events that happened to a transaction, plus you can get the transactions in the CSV report or a detailed PDF report about a particular transaction.

If you miss some reporting feature, contact us, and we will try to satisfy your request.

How do I get reports on certain users or transactions of interest?

Set up a filter that matches your criteria and get a CSV export. If you miss some filters, contact us and we will add them for you.