Crypto KYT for EMIs and payment institutions
Screen crypto on- and off-ramps at the boundary, and evidence them like the rest of your file. Your AML programme is mature on every rail except the one where the counterparty is an address instead of an IBAN.
The rail your monitoring system cannot see
An EMI's transaction monitoring was specified around payments that carry a name: a SEPA credit transfer, a card authorisation, a direct debit. Every rule in it, whether velocity, geography, counterparty risk or peer-group deviation, assumes there is a party to reason about. A crypto on-ramp arrives with an address, a chain and an amount. The monitoring system either ignores it or treats it as a cash-in from an unnamed source. Either way it is a blind spot with a policy written over it.
The gap rarely comes down to a missing chain-analytics licence. The crypto leg lives in a different system from the euro leg, so the file a supervisor reads is put together by hand, late, by the only person who understands both.
The crypto leg and your existing obligations
As a financial institution you are an obliged entity now, and you remain one under the EU regulation that applies from 10 July 2027, where due diligence on transfers of funds is triggered at EUR 1 000. The newer questions are specific to the rail. Can you show that the transaction you credited settled on-chain with that amount? Can you show that the counterparty address was screened against current list data rather than a quarterly download? And can you show what you did when a list changed after you had already paid?
Travel Rule data is a useful test case. KYTGate does not send Travel Rule messages and does not join a messaging network. It stores what your crypto-asset service provider already passes you, checks its structure and drops natural-person names. When nothing arrives, the coverage matrix shows the dimension as MISSING, so the gap is visible instead of sitting in an empty field.
How KYTGate fits beside your existing stack
KYTGate sits next to your monitoring system rather than replacing it. You make one API call per on-ramp, off-ramp or crypto-funded payout, and get back a decision, a coverage matrix across nine dimensions and a signed receipt. The decision is deterministic and can be replayed. The stored inputs and that day's policy version reproduce it exactly, with no provider re-queried, so the answer you give an examiner next year matches the one you give today.
If you already license Chainalysis or Elliptic, connect that licence with your own key. KYTGate calls it, quotes its answer as the vendor's own, and files that answer in the same case, receipt and replay as everything else. The contract and the bill stay yours, and the work stays in one workflow.
Three common situations
Your TM system has no chain data
Run KYTGate in shadow mode on the crypto leg for a month. Every on-ramp gets a second, public-source opinion, and any disagreement with your existing result is visible. It is a cheap way to size the gap before you commit to anything.
Travel Rule data arrives incomplete
It is stored as received, checked for structure and reported as a coverage state instead of being treated as satisfied. The file shows what your CASP sent and what it did not.
An address you paid is designated three weeks later
Re-screening against fresh list snapshots reopens the question automatically and creates a case. The original receipt stays intact for the day the payment was made.
Best fit: authorised EMIs, payment institutions and fintechs adding a crypto on- or off-ramp, whose AML function is already mature and needs the new rail to produce the same quality of file as the old ones.
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.