A texted link asking questions is exactly what phishing looks like.

Correct, and it is the sharpest design constraint on the product. The page never asks for a password, a one-time code, a card number, or for money to move — and it says so on every screen. In gate mode it gives the customer a code rather than asking for one, which inverts the phishing shape entirely. Sender IDs are registered, the domain is yours, and you can pre-notify customers that the check exists.

How do you stop a thin check from reading as a clean one?

Every indicator resolves to raised, clear, or unknown, and unknown is reported everywhere the other two are. The score is normalised only over what we could actually test, and it always travels with the coverage behind it. Below 40% coverage the verdict is 'insufficient', never 'low' — because a barely-examined channel is not a safe one.

What if the payment was raised in branch or over the phone?

InstructionCheck reaches the customer out-of-band, so it works regardless of where the payment was raised. Session-bound vendors are blind by construction when there is no device and no behavioural telemetry; the instruction is still reachable.

Instruction Verification

You verify where the money came from.
Nobody verifies the instruction.

Q: Won't a coached victim just lie to it?

Some will, and we do not claim otherwise. What we claim is narrower and provable: we collect evidence the customer cannot easily fabricate, and we check it independently. The address they paste is tested against the registry, DNS, mailbox classification, and your watchlist — none of which the scammer coaching them controls. Corroboration questions fire precisely when an exculpatory claim is made, and a contradiction between two answers is itself a finding. We raise the cost of coaching and hand you evidence you did not have. That is not lie detection, and we will not sell it as such.

Every authorised push payment scam begins with an instruction that reached your customer through a channel you cannot see. InstructionCheck captures that instruction, verifies the source behind it, and returns a scored risk signal — one API call, no SDK, no app release.

See the live check

Reimbursement shift

100%

Of authorised-push-payment losses now land on sending banks under UK rules, with the same shift underway in other markets.

Signals that stay clean

Every one

Real person, real device, normal behaviour. Your existing stack says the payment is fine, because on its own terms it is.

Time to first signal

<10 min

From sandbox key to a scored verdict on your own webhook. If it takes longer, we treat that as a bug.

The category

A third source your controls already have a shape for.

Your onboarding and AML teams have asked two source questions for decades. This is the third, and it is the one that decides whether a payment was a scam.

Source of FundsWhere did the money come from?Established, documented, audited.
Source of WealthHow was it accumulated?Established, documented, audited.
Source of InstructionWho told them to send it?Nobody asks. It is the only one a scammer controls.

How it works

Three steps, and only one of them is yours.

01
You call the API
One POST with the customer's number and the payee. No SDK, no app release, no change to your payment flow.
02
The customer answers
A bank-branded page reaches them by SMS or email. Three to five questions, about thirty seconds. It never asks for a secret.
03
You get the signal
A scored verdict on your webhook — with the coverage behind it, the indicators that fired, and a recommendation your gate already speaks.

Live check

Run a real check, see the webhook.

This is the customer-facing page exactly as it arrives — a plain bank page, three to five questions, no secrets requested. Answer it and the scored verdict your webhook would receive appears below.

Get a Demo Try the sandbox

Northwind BankSecure

Text message

Northwind Bank: before we release your payment to Acme Roofing, please confirm how you received the payment details. This takes about 30 seconds and will never ask for your password, a code, or your card number.nwb.uk/c/8fk2qd

What it catches

Nineteen weighted indicators, two families.

Direct findings are true on their own. Gap findings are contradictions between two facts — and they carry more weight, for the same reason a discrepancy beats a smell.

Redirected invoices

The invoice arrives from a domain that borrows the supplier's name. The customer cannot tell; a registry lookup and a name comparison can.

Safe-account calls

Someone is still on the line while your customer completes the check. In a genuine payment, nobody is.

Freshly built channels

A domain eleven days old is billing for a relationship the payment implies is years old.

Coached self-initiation

The customer says nobody sent the details, then says they followed a link someone sent. The contradiction is the finding.

Deployment

Consume it as a signal, or put it in the way.

Mode: Signal

Feed your existing decisioning

The verdict lands on your webhook and flows into the rules engine you already run. The customer journey is unchanged; you simply know something you did not know before. Start here. Most banks do.

Mode: Gate

Stand between the victim and the money

You already text a confirmation code at wire time. Send the check instead: the customer sees the code only after answering, and after reading a warning written for the scam we think is happening. Your verify step does not change.

Integration

Live in an afternoon.

There is nothing to embed. No SDK in your app, no release train, no mobile review cycle, no change to the payment screen. If you can make an HTTPS request and receive a webhook, you are integrated. Built on the KYRi™ scam engine, part of the ActionID™ platform — InstructionCheck upgrades into the full in-session KYRi™ experience without a re-integration.

curl -X POST https://api.instructioncheck.dev/v1/checks \
  -H "Authorization: Bearer $ICK_KEY" \
  -d '{
        "customer": { "phone": "+447700900000" },
        "payment": {
          "payee_name": "Acme Roofing",
          "payee_is_business": true,
          "amount": 2750, "currency": "GBP"
        },
        "mode": "gate"
      }'

The response carries the release code for you. Your customer has to earn it.

Pricing

You pay for signals you actually receive.

Sandbox

Free

Full engine, full API, test keys. Send yourself a real check on your own phone.

Production

Per completed check

You pay when a customer answers. Undelivered and abandoned checks are free — you should not be billed for a signal you did not get.

Enterprise

Talk to us

Your own domain, adaptive depth, WhatsApp delivery, SSO, DPA, and a deployment conversation with your risk team.

Talk to us

Frequently Asked Questions

Have questions? Look here.

Some will, and we do not claim otherwise. What we claim is narrower and provable: we collect evidence the customer cannot easily fabricate, and we check it independently. The address they paste is tested against the registry, DNS, mailbox classification, and your watchlist — none of which the scammer coaching them controls. Corroboration questions fire precisely when an exculpatory claim is made, and a contradiction between two answers is itself a finding. We raise the cost of coaching and hand you evidence you did not have. That is not lie detection, and we will not sell it as such.

Verify the instruction behind every payment.

See how InstructionCheck plugs a scam-specific signal into the fraud stack you already run — without touching your payment flow.