I integrated AML checks into my code. The API request was the easy part.
I was adding wallet screening to a product that processes crypto payments. I wanted the team to see a risk assessment before deciding what to do with an address.
The first request was straightforward. My backend sent the wallet address, currency and network to AMLKYC.TECH:
PUT /api/fast-check
For a USDT transfer on TRON, I used currency=usdt and network=trx. That distinction matters because a check for USDT and a check for TRX at the same address are different assessments.
The API returned a check ID, which I saved alongside our internal payment record. Then I fetched the result with:
GET /api/fast-check/{id}
The part I spent more time on was handling the period between those requests. A newly submitted check enters a queue. I kept the payment in a “screening pending” state and waited for the check to finish before reading its risk score and labels.
I also had to account for repeat checks. If I submit an address we have checked before, the response can still contain data from the previous run while the new one is processing. Showing that old score as a fresh result would give our review team the wrong picture.
Once the new result was ready, I stored the score, relevant risk details and check timestamp. Higher-risk cases went to a person for review, with a link back to the screening record.
The integration taught me something familiar from payment systems: returning a result is only one part of the workflow. The status, timing and evidence behind it determine whether the result is useful.
If you’re building crypto payments, exchange software or a wallet product, the API documentation is here:
How are you handling pending checks in your own payment flow?
Top comments (0)