Advanced: blockchain and AI in cyber and transaction security.

Attacking the models that guard transactions

Banks and payment providers increasingly use machine learning to score transactions for fraud, monitor for money laundering and prioritise screening alerts. Those models are themselves targets.

The US National Institute of Standards and Technology (NIST) set out the attacks in NIST AI 100-2 E2025, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations (March 2025). (A naming note: in NIST's report, "AML" means adversarial machine learning, not anti-money laundering.) It classifies attacks by when they happen, what the attacker wants (to break availability, integrity or privacy), what they can control and how much they know about the model.

The three main attacks on predictive models:

• Evasion, at the time the model is used: the attacker crafts inputs to get the decision they want, without changing the model. NIST notes evasion attacks against financial applications, and real-world attacks on face recognition used to commit benefit fraud.
• Poisoning, at training time: the attacker corrupts the data or the model itself. A backdoor is a hidden trigger planted in training that makes the model misbehave whenever the trigger appears. NIST observes that the documented real-world poisoning cases hit systems that were continuously retrained, because attackers counted on their poisoned data being absorbed.
• Privacy attacks, including model extraction: rebuilding a working copy of a model by repeatedly querying it, which then lets the attacker plan evasion offline, and membership inference, learning whether particular records were in the training data.

How this could look in transaction security (our illustration; NIST gives no AML or fraud worked example):

• evasion: shaping payments so their features fall just inside what a fraud or monitoring model treats as normal;
• poisoning: manipulating the feedback that retrains a model, such as alert outcomes or customer disputes, so a pattern is learned as legitimate;
• extraction: probing a screening or scoring service with many test transactions to learn where its thresholds lie.

Generative AI adds prompt injection. NIST explains that generative models mix data and instructions in the same channel, so text hidden in a document or web page the model reads can steer it. Any assistant used in investigations or customer service should be designed on the assumption that this is possible.

Defending machine learning models

NIST's honest warning. NIST says the machine learning methods in wide use have no mathematical proofs of security, and that many defences are empirical and limited, and may fail against new attacks. Defending against evasion while keeping accuracy is still an open problem. Defence is therefore about raising the attacker's cost and limiting damage.

What the guidance recommends:

• Control the training data: know where data comes from, protect its integrity through the pipeline, sanitise it, and restrict who can change it (NIST AI 100-2; ENISA). Verify the integrity of third-party data and treat pre-trained models from outside as untrusted components.
• Be careful with automatic retraining: check for poisoning after evaluation, before production and regularly afterwards (ENISA), given that real poisoning cases targeted continuously updated systems.
• Make models harder to fool: add adversarial examples to training, and test robustness against attackers who adapt (NIST; ENISA), accepting some cost in accuracy and computing.
• Reveal less: limit how much detail the model returns, limit and watch queries for probing patterns, and restrict information about the model (ENISA; NIST notes determined attackers can get round query limits).
• Monitor in production: dashboards and indicators for sudden changes in model behaviour (ENISA), and ongoing monitoring of functionality and behaviour (NIST AI Risk Management Framework).
• Be able to switch it off: the NIST framework expects mechanisms to override, disengage or deactivate a system behaving outside its intended use.
• Bring models into normal security processes: asset inventories, red-teaming and incident response.

Frameworks. The NIST AI Risk Management Framework (2023) organises AI risk management into four functions, Govern, Map, Measure and Manage, and lists characteristics of trustworthy AI, including being secure and resilient, which it links to adversarial examples, data poisoning and theft of models or training data. ENISA's 2021 report on securing machine learning algorithms identifies six threats, including evasion, probing ("oracle") attacks and poisoning, and proposes 37 controls, adding that conventional security controls must be complemented by controls specific to machine learning. ENISA's 2023 framework treats AI security as an addition to existing cybersecurity, not a replacement.

What blockchains do and do not secure

Permissionless and permissioned. NIST's 2018 overview of blockchain technology (NIST IR 8202) explains the difference. In a permissionless blockchain anyone can publish blocks, and consensus methods such as proof of work or proof of stake make it costly to cheat. In a permissioned blockchain, only authorised participants can publish, which is faster and cheaper and lets authorisation be withdrawn.

Where the risks really are:

• Private keys. NIST says losing a private key means losing the assets it controls, and stealing it gives full control of them. Most reported thefts mean keys were stolen, not that the blockchain itself was broken, and once transferred, funds generally cannot be recovered by reversing the transaction.
• Majority attacks. An attacker controlling more than half of the block-producing resources can rewrite recent history. NIST notes this is not technically difficult, just expensive. In a permissioned chain, the owners can legitimately rewrite blocks, which is a governance question in itself.
• Ordinary cyber risks remain. NIST is clear that blockchain does not remove inherent cybersecurity risks: denial of service, time manipulation and vulnerable new code are all routes in, and existing frameworks still apply.
• Smart contracts and oracles. Contracts must behave deterministically, and data from outside the chain enters through oracles, which the chain cannot verify. The Financial Stability Board noted in 2024 that smart contract security practices are still evolving, that coding errors may be hard to fix once deployed, that oracles can be manipulated, and that custodians may struggle with robust key management.
• Who is responsible? On permissionless chains there may be no contractual party responsible for managing operational risk, the FSB adds, and 24-hour operation increases operational demands.
• Cryptography ages. NIST notes a flaw in an algorithm, or a practical quantum computer, could force a change of algorithms across the whole network.

The practical lesson: a blockchain changes where the risks sit, mostly towards keys, code and governance, rather than removing them.

Central banks testing tokenised payments

The unified ledger. In a 2023 report, the Bank for International Settlements (BIS) proposed the concept of a unified ledger: a programmable platform bringing together central bank money, tokenised bank deposits and other tokenised assets. It warned that concentrating data raises concerns about theft and abuse, that security needs several layers of protection, from encryption and access control to monitoring and audit, and that a ledger covering more activity creates a bigger single point of failure.

Project Agorá. Launched by the BIS in 2024 with seven central banks, including the Bank of England, the Federal Reserve Bank of New York and the Bank of Japan, and more than 40 private financial firms, Agorá is testing a common, programmable platform for wholesale payments across borders, settling in tokenised forms of central bank money and of commercial bank deposits, aiming for atomic settlement, in which both sides settle together or not at all. The BIS stresses that its innovation projects are experiments, not finished products.

What Agorá shows for security and screening:

• Its May 2026 report is open that the prototype was not built to production standards of cyber security. Key custody, key management, formal threat modelling and penetration testing were out of scope and would need full design before any real system.
• Real-value testing in 2026 added maker-checker approval, manual approval points and multi-factor authentication.
• Screening stays with the banks. Each bank runs its own sanctions screening, anti-money laundering, know-your-customer and fraud checks in its own systems and returns only a pass or fail flag to the platform. Any fail stops the payment. The platform records the attestations but does not perform the checks, and no customer data is shared.

Tokenisation and risk. The CPMI and BIS told the G20 in 2024 that the familiar operational and cyber risks of payment systems apply to tokenised arrangements, that self-executing programs may introduce errors, theft or availability problems, and that risk rises when many participants rely on the same programs.

Kenya. After consulting on a central bank digital currency, the Central Bank of Kenya said in June 2023 that a CBDC "may not be a compelling priority in the short to medium term", and that it would keep monitoring developments.

The rules that connect them

Crypto firms under operational resilience law. The EU's Digital Operational Resilience Act (DORA), applying since 17 January 2025, covers crypto-asset service providers authorised under the Markets in Crypto-Assets Regulation (MiCA). MiCA in turn requires them to use resilient and secure ICT systems as DORA requires, with business continuity and response and recovery plans, and to protect the availability, authenticity, integrity and confidentiality of data.

The AI Act's robustness requirement. Article 15 of the EU AI Act requires high-risk AI systems to achieve appropriate accuracy, robustness and cybersecurity throughout their lifecycle. It names the attacks from the first lesson, calling for measures against data poisoning, model poisoning, adversarial examples (model evasion), attacks on confidentiality, and flaws in the model. It also requires care with feedback loops in systems that keep learning.

Most fraud detection and anti-money laundering models are not high-risk under the Act: AI used to detect financial fraud is expressly carved out of the credit-scoring category, and transaction monitoring is not listed. Article 15 is still a sensible benchmark for any model that guards transactions.

Bringing it together:

• treat models that score, monitor or screen transactions as security assets: inventoried, access-controlled, monitored and covered by incident response;
• protect the data and feedback loops that train them;
• test models adversarially, not only for accuracy;
• on blockchain and tokenised systems, focus on keys, code, oracles and governance;
• keep screening and decisions within accountable institutions, as Agorá does.

In Kenya: the Virtual Asset Service Providers Act, 2025 requires licensed providers to have appropriate and effective cyber security measures, as prescribed or as provided under the Computer Misuse and Cybercrimes Act, considers those measures when granting licences, and requires the chief executive to notify the regulator of a cyber security incident and send a written report within seven working days. The Kenya National AI Strategy 2025–2030 recognises that AI can be exploited for cyber attacks and plans AI-specific threat detection and response across critical sectors. The Central Bank published a draft guidance note on AI in banking for comment in 2026; check the current position.

Your certificate of completion

Enter your name as you want it to appear, then save the certificate as a PDF. In the print window, choose Save as PDF. A certificate is issued once per completion of the course.

Saolix does not record who takes this course, so it cannot verify these certificates. The certificate confirms completion of a free self-paced course and is not an accredited qualification.