Crypto KYT for payment processors and PSPs
Give your merchants the evidence behind each screening and keep an independent record of your own decisions. Your merchants inherit your screening outcome. When their regulator asks what it was based on, 'the processor said yes' should not be the whole answer.
The evidence gap between you and your merchants
Most crypto processors screen well and pass on very little. A webhook carries approved: true, and the merchant's compliance file ends there. To a supervisor, that is an unverified assertion from a third party. Merchants who take compliance seriously, regulated brokers in particular, increasingly ask for the underlying signals, the list versions and a reference they can cite.
There is a second problem on your side. Your own decisions are made by a pipeline that changes over time. Reproducing why a specific transaction was approved six months ago, under the rules of that day, is hard unless the inputs and the policy were captured together at decision time.
Two ways processors use KYTGate
The first is as an evidence layer for merchants. You forward your KYT assessment, with an evidence reference, to the merchant's KYTGate tenant as a processor signal. The merchant's coverage matrix then reads processorEvidence COMPLETE and their assurance tier rises to PROCESSOR_ATTESTED. Your assessment becomes part of a signed, replayable record that the merchant controls.
The second is as an independent control plane for your own decisions. Run KYTGate in shadow mode alongside your existing pipeline. Every transaction gets a second opinion from public sources (sanctions lists, issuer freezes and transaction integrity), and any disagreement with your own result is visible. It is a cheap way to find blind spots, and it gives your bank and your auditors something concrete to review.
Integration notes
Processor connectors are built against a fixed contract. A connector verifies the webhook signature, fetches the transaction, extracts the KYT assessment and evidence, extracts originator and beneficiary, fetches settlement and maps the status. A connector is published only once it runs in production with a real merchant, so this site has no 'coming soon' integration pages. To be one of the first, start with a sandbox tenant and one merchant willing to run shadow mode.
Three common situations
A merchant asks what you checked
With evidence references in your signals, the merchant's evidence pack cites your assessment alongside the public-source checks and the list snapshot hashes, so one download answers the question.
Your pipeline and public sources disagree
Shadow mode records the conflict as a coverage state and does not pick a winner. You decide what to do with it, and the record shows both results.
A merchant is examined a year later
Replay reproduces the decision deterministically from the stored inputs and that day's policy version. No provider is re-queried, so the answer cannot drift.
Best fit: crypto payment processors and PSPs serving regulated merchants, who want their screening to produce transferable evidence rather than a status, and want a second opinion on their own pipeline.
Still working out which obligations apply to you? Who must screen crypto payments sets out the two layers: sanctions, which bind every EU business today, and due diligence, which binds a defined list of sectors from 2027, with the source next to each row.
Decision-support software, not legal advice. Which obligations apply to you depends on your licence and structure; confirm with counsel.