The Technology Risk Assessment is a statutory AML/CFT requirement, not an IT housekeeping task. Under Code §7(1), a relevant person must carry out an assessment that estimates the risk of money laundering and terrorist financing posed by any technology to its business. It is one of three documented assessments the Code requires — sitting alongside the Business Risk Assessment (BRA, §5) and the Customer Risk Assessment (CRA, §6) — and it feeds directly into the BRA. The point of a TRA is not whether your systems are secure; it is whether the technology you rely on raises or lowers your money laundering, terrorist financing and proliferation financing risk, and how it affects your AML/CFT/CPF controls. If your firm has never produced a standalone TRA, or has assumed an IT security review covers it, that is a gap a supervisor can see. This is the assessment that genuinely bridges compliance and IT.
This is also the assessment firms most often miss. The BRA and the CRA are familiar; the TRA is frequently absent, folded into something else, or inherited wholesale from a group without being read. Below we set out what the Code actually requires.
What is a Technology Risk Assessment?
A Technology Risk Assessment is the documented exercise required by Code §7(1): an assessment that estimates the risk of money laundering and terrorist financing posed by any technology to the relevant person's business. The Code is explicit about scope — under §3(1), the technology risk assessment "includes both new and developing technologies." It is not limited to the systems you have run for years; it reaches the ones you are about to adopt.
The April 2026 AML/CFT Handbook (§2.2.11) sets out the purpose plainly. The TRA exists so that relevant persons fully understand the ML, FT and proliferation financing risks arising from any technology, and the impact that technology may have on compliance with AML/CFT/CPF requirements — whatever the technology used. Technology can improve the effectiveness of your AML/CFT controls. It can also weaken them if it is applied badly or without sufficient understanding of how it works. The TRA is where you evidence that you have thought this through, rather than assumed the system "just works".
We help Isle of Man firms map each piece of technology they rely on to its ML/FT/PF risk, and document it to the Code's standard.
TRA vs IT security audit — not the same thing
This is the distinction that catches firms out. An IT security audit asks whether your systems are protected — patched, access-controlled, resilient to attack. A Technology Risk Assessment asks a different question: does this technology raise or lower my money laundering, terrorist financing and proliferation financing risk, and does it strengthen or weaken my AML/CFT/CPF controls? The two overlap, but they are not interchangeable, and one does not satisfy the other.
A worked example makes the difference concrete. An electronic onboarding and e-ID system might pass an IT audit with no security findings, yet still introduce real AML/CFT risk — non-face-to-face onboarding, reliance on a third party's verification logic, false confidence in an automated decision. The security review would not surface that; the TRA is designed to. This is the same governance-first point the firm's IT advisory makes elsewhere: technology risk does not sit with IT alone. The TRA is a compliance assessment that happens to be about technology, and it belongs to the same accountable people who own the BRA and the CRA.
When must you do a TRA?
The Handbook (§2.2.11.1) sets a timing expectation rather than an annual tick-box. You assess the technology before, or at the point of, adopting it — and again on change. The TRA is not a document you write once and file; it is reviewed whenever the technology, or your use of it, changes materially.
The scope of "technology" here is deliberately wide because §3(1) brings new and developing technologies into the assessment. In practice that means the things firms are adopting fastest: AI tools used in monitoring, screening or analysis; new electronic onboarding and e-ID systems; and crypto and virtual-asset rails where a firm touches them. Adopting any of these without a TRA is the most common version of the gap. The Handbook (§2.2.11.2) also points to the relevant risk factors to weigh — how the technology is used, where, by whom, and what it touches in your AML/CFT/CPF process — so that the assessment reflects your firm, not a generic statement about the product.
Group systems and inherited technology
Many Isle of Man firms run technology chosen at group level — a group onboarding platform, a group transaction-monitoring system, a group AI tool. The Code anticipates this. Under §7(2)(b), where new products, services, delivery methods or systems are introduced by a group, the relevant person must ensure the group's risk assessment of that technology is sufficiently granular and specific to its own needs. If it is not, the firm must carry out its own.
The practical failure here is inheriting a group assessment wholesale and treating the question as answered. A group-level TRA written for a large multinational arm may say nothing useful about how the system behaves for a small Isle of Man book of business, the local customer base, or the Manx regulatory framing. "The group has assessed it" is not, on its own, a defensible position. You must read the group assessment against your own operation and either rely on it because it is genuinely granular to you, or produce your own — and document which.
How the TRA connects to your BRA, CRA and IT governance
The TRA does not stand alone. It is one of three documented assessments the Code requires — the BRA under §5, the CRA under §6, and the TRA under §7 — and they operate as a connected set, not three filing-cabinet exercises. The TRA feeds the BRA: what you conclude about your technology's ML/FT/PF risk should be visible in your firm-wide business risk picture, the same way your customer risk picture is. A BRA that says nothing about the systems the firm runs on is incomplete.
This is the firm's "don't file it and forget it" position applied to technology. Just as the statistical return is the evidence behind your BRA, the TRA is the evidence behind how your technology shapes your risk — and it should be reconciled with the rest of your framework, not parked. It also sits at the seam with IT governance and cyber: the same systems your TRA assesses for ML/FT/PF risk are the ones your cyber and resilience work protects, and your TRA conclusions are part of the broader current Handbook picture set out in our April 2026 AML/CFT Handbook guide. Treated together, they make the firm defensible; treated separately, they leave gaps between the silos.
Common mistakes we see
The recurring problem is simply not having a standalone TRA — relying on the BRA, a policy document, or an IT review to cover a duty the Code states separately under §7. Close behind is conflating the TRA with cyber security: a clean penetration test or security audit tells you your systems are protected, not that you have assessed their ML/FT/PF risk. A third is ignoring new and developing technology — adopting an AI monitoring tool or a new e-onboarding system and never running it through a TRA, even though §3(1) puts exactly those technologies in scope. And finally, inheriting a group assessment without checking it is granular enough for your firm, which §7(2)(b) does not permit.
None of these is hard to fix once the duty is clear. The work is to identify the technology you rely on, assess each piece against ML/FT/PF risk, link it back to your BRA, and review it on change. We help Isle of Man firms produce a TRA that holds up — distinct from their cyber review, reconciled to their BRA and CRA, and ready for a supervisor to read.
Frequently asked questions
What is a Technology Risk Assessment under the AML/CFT Code?
It is the assessment required by Code §7(1): a relevant person must estimate the risk of money laundering and terrorist financing posed by any technology to its business. Code §3(1) confirms it includes both new and developing technologies. Its purpose, set out in the April 2026 Handbook (§2.2.11), is to make sure firms understand the ML, FT and proliferation financing risks arising from their technology and the impact that technology has on AML/CFT/CPF compliance.
Is a TRA the same as an IT security audit or cyber-security review?
No. An IT audit or cyber review asks whether your systems are secure; a TRA asks whether the technology raises or lowers your ML/FT/PF risk and how it affects your AML/CFT/CPF controls. A system can pass a security audit and still carry money laundering risk a TRA is designed to surface. The two are complementary, but one does not satisfy the requirement for the other.
When does an Isle of Man firm need to carry out a TRA?
You assess the technology before or when you adopt it, and again on change — the Handbook (§2.2.11.1) sets a timing expectation rather than a fixed annual date. Because Code §3(1) brings new and developing technologies into scope, adopting AI tools, new electronic onboarding or e-ID systems, or crypto and virtual-asset rails should each trigger a TRA or a review of an existing one.
Can we rely on a group technology risk assessment?
Only if it is sufficiently granular and specific to your firm. Code §7(2)(b) requires you to check that a group's assessment of new products, services, delivery methods or systems fits your own needs; where it does not, you must carry out your own. Inheriting a group TRA wholesale, without reading it against your operation, is not a defensible position.
