AI scam detection moves the question to before a transfer

Alterya, a named OKX adoption announcement and payment-industry tools shift attention to recipient evidence before a transfer, with important limits.

A payment can be authorised by the person making it and still be part of a scam. That is a different problem from someone secretly taking over an account. The distinction helps explain a development in crypto-related fraud tools: some suppliers are trying to connect suspicious recipients and online activity before a transfer, rather than relying only on tracing funds after a complaint.

Chainalysis’s January 2025 acquisition announcement for Alterya described AI-powered fraud detection across crypto and fiat identifiers, with an emphasis on preventing illicit transfers. It also reported customer and monitoring figures, but those promotional outcomes are not adopted here as independently verified effectiveness. The concrete development is the acquisition and the supplier’s described expansion from investigation toward earlier fraud detection. [Chainalysis’s Alterya announcement](https://www.chainalysis.com/blog/chainalysis-alterya-announcement/).

A named customer announcement followed in February 2026. Chainalysis and OKX described plans for Alterya screening to help prevent transfers to known scam destinations, with recipient-side information and evidence-backed alerts for review. The release says OKX “will adopt” the system. Its headline should not be treated as independent confirmation of a completed rollout, and its reported savings or reduction figures are not evidence that every transfer will be classified correctly. [The OKX and Chainalysis announcement](https://www.chainalysis.com/blog/okx-adopts-alterya-fraud-prevention-february-2026/).

The question changes with the stage

After a transfer, an investigator may ask where funds went and what records support a lead. Before a transfer, a service may instead ask whether information about a proposed recipient warrants a pause or further explanation. The two activities can inform one another, but they have different timing, responsibilities and opportunities to intervene. An explanation of a risk signal is not the same as a tracing result.

The label “AI fraud detection” can conceal that difference. A model might help organise reports, connect patterns or summarise material for a reviewer. A separate process determines whether the information is relevant to the proposed transaction and what response is permitted. The public announcements do not supply all those operating details, so this article does not reconstruct a vendor’s private model or recommend a particular service.

Mastercard’s April 2024 Scam Protect announcement describes another combination: AI-based identity and transaction information, collaboration with other organisations and consumer education. It includes higher-risk transaction authentication as part of the design. This is a first-party launch account across payment contexts, not evidence that a particular crypto platform uses it or an independently measured prevention result. [Mastercard’s Scam Protect announcement](https://www.mastercard.com/us/en/news-and-trends/press/2024/april/mastecard-transforms-the-fight-against-scams-with-latest-ai-tech.html).

The FBI’s December 2024 public advisory explains why a person’s confidence can be misleading. It describes generated text, images, audio and video supporting impersonation and financial fraud, including fabricated investment websites. It recommends independent identity checks rather than relying on a convincing interaction. This is a prevention advisory, not a prevalence survey or a test proving that people can reliably recognise synthetic media by appearance. [The FBI’s primary advisory](https://www.ic3.gov/PSA/2024/PSA241203).

These accounts suggest two separate questions. Did the person genuinely request the payment? Is the recipient or surrounding story supported by trustworthy information? Authentication can help address the first without resolving the second. Equally, a recipient alert should not automatically establish that a person committed a crime. A careful explanation gives each question its own evidence.

A fictional prevention exercise

Consider fictional adult customer-support and risk trainees in Barcelona. They use invented conversations and recipient cards in a classroom exercise. No real wallet address, bank account, customer identity or transfer appears. The facilitator provides both an invented scam report and a superficially similar legitimate case, so the group cannot succeed merely by treating every unusual request as suspicious.

In the first case, the synthetic customer confirms that they intended the transfer. A separate recipient card contains a reported concern with a stated date and an unresolved matching question. Learners identify what that report supports and what it does not. The exercise should not quietly convert a possible match into certainty because the assistant’s summary uses a confident name.

The second case contains an outdated note. Learners compare the date and scope with the current synthetic request. If an assistant repeats the earlier warning without explaining its status, they mark the omission. If it declares the recipient safe simply because the note is old, they mark that unsupported inference too. The aim is a better-supported question, not a predetermined decision.

The group then practises a plain-language explanation. It should state what information remains uncertain and which separate review is needed, without exposing private reports or internal detection details. It should not tell a fictional customer that a transfer succeeded when the exercise provides no completion record. This connects fraud review with understandable service communication rather than treating them as unrelated tasks.

An independent learner receives the explanation and describes what they would expect to happen next. A mismatch reveals that technically accurate wording can still mislead. For example, “reviewed” might be understood as “approved,” although the supplied record only shows that someone opened the case. The correction should improve the wording without overstating the result.

The facilitator closes the exercise with a comparison of the two cases and their unresolved questions. No actual payment is submitted, no warning is tested against a real person and no private data is gathered. The activity is an original educational illustration, not an account of a real vendor’s training, a completed fraud investigation or a recommendation to move assets.

The benefits and trade-offs worth examining

Earlier information may create an opportunity for a better conversation before an irreversible event. A reviewer may receive context that would otherwise remain spread across reports or systems. A customer may understand why a question is being asked instead of seeing an unexplained refusal. These are potential benefits to evaluate; the fictional activity demonstrates no prevented loss.

There are costs when a system gets the distinction wrong. An unsupported warning can delay a legitimate transaction or unfairly associate someone with a concern. An overly reassuring answer can encourage reliance on incomplete information. A useful evaluation therefore includes incorrect matches, missing records, changed notes and disagreements between reviewers, as well as straightforward examples.

Privacy also belongs in the discussion. Combining information across payment contexts does not make every available data item necessary or appropriate. A public product description does not establish the authority for a particular use of personal records. This article offers no individualized financial or legal advice and no assurance of recovery, reimbursement or detection.

The acquisition, customer announcement and payment-industry launch show that prevention before transfer is a real product direction. The important learning is to distinguish the person’s request, recipient evidence, review and actual transaction state. AI may assist parts of that work, but the usefulness of an alert depends on whether people can understand and examine what it supports before treating it as a decision.

Evidence diagram and readable guide


Original explanatory diagram: a fictional adult exercise keeps a request, recipient information, identity and risk review distinct; no actual transfer, fraud finding or prevented loss is shown.

[Open the complete evidence diagram](/assets/crypto-evidence-before-transfer-20261016.svg)

Read the diagram

**AI scam detection moves the question to before a transfer**

A fictional adult prevention exercise with invented conversations and recipients; no real account, transfer, allegation or prevented loss.

- **Synthetic customer request** Retain what the fictional person intended.

- **Recipient information** Keep report dates and matching questions visible.

- **Identity confirmation** Separate the person's request from recipient safety.

- **Separate risk review** Inspect uncertainty and possible innocent explanations.

- **Plain state explanation** Explain what is supported and what remains open.

- **Scoped comparison record** Retain corrections without claiming prevented loss.

Identity confirmation and recipient-risk review are different inputs. Neither a genuine request nor a warning alone establishes the full situation.

How the connections work

- The synthetic request supports confirmation of the fictional person's intention.

- Recipient information supplies separate evidence for the risk review.

- Identity confirmation informs the explanation without establishing recipient safety.

- The risk review supplies its own limited context to the plain explanation.

- The explanation is retained for comparison with what a separate learner understood.

- A changed note can reopen the recipient question without submitting any transfer.

Relationship key

Identity confirmation and recipient-risk review are distinct inputs to an explanation. The dashed return reopens changed recipient information for review; it does not authorise or submit any transfer, or establish prevented loss.