← Back to Blog

Signal, Not Solution: How Authorization Infrastructure Integrates With Your Fraud Stack

The first question a bank security architect asks about authorization infrastructure is also the most important one: does it replace the fraud stack we already run? The answer is no — and the post explains why that is a feature, not a limitation.

The Standard Objection

A CISO or a bank fraud architect hears the pitch for authorization infrastructure and asks a sensible question:

“We already run Actimize, or Featurespace, or Sardine. We have behavioral-biometrics vendors, device-fingerprinting, graph-based risk models. Where does this fit? Are you replacing them?”

The honest answer is no, and the reason is architectural. Authorization infrastructure addresses a different layer of the problem than fraud scoring. It does not compete with fraud engines — it changes what they can resolve.

What Fraud Engines Actually Compute

A modern fraud engine evaluates each transaction against a probabilistic model. The model combines dozens to hundreds of signals:

  • Device fingerprint and reputation history.
  • IP geolocation, ASN, known proxy / Tor exit.
  • Velocity (transactions per minute, amount distribution).
  • Behavioral biometrics (typing cadence, pointer dynamics).
  • Graph features (shared devices, shared counterparties, mule rings).
  • Payee reputation, account age, Confirmation of Payee match.
  • Time-of-day, channel, historical patterns for this customer.

The output is a probability, not a certainty. That is deliberate — the engine is compensating for things it cannot observe directly. The most important of those unobservables is a single question:

Is the authorized human actually at the keyboard right now?

Fraud engines cannot answer that question directly. They answer an adjacent question: given the signals we observe, how likely is it that the authorized human is at the keyboard? That is a probability, and probabilities produce false positives and false negatives.

Why Probabilistic Models Struggle With Modern Attacks

Attackers have learned to produce signal profiles that look legitimate to probabilistic models:

  • Remote-access trojans operate on the customer’s real device — so device fingerprint, IP, and reputation all look clean.
  • Session-hijack tools (EvilProxy, Tycoon 2FA) replay a real session token — so the session signals look legitimate.
  • SIM-swap attackers use the customer’s real phone number to receive OTPs — which the bank treated as authentication.
  • Behavioral biometrics can be approximated by bots trained against the same signal sources.

The remaining probabilistic signal that remains hard to forge is the presence of the specific human’s body at a specific device in the moment of the action. That is the signal authorization infrastructure produces directly. When the fraud engine receives it as a clean binary input, its models get sharper immediately.

The Binary Field

Authorization infrastructure contributes one field to the fraud engine’s decision context:

human_verified = true | false

The field is produced the moment an action is attempted. Its value is a direct cryptographic answer to the previously-unobservable question: was a fresh biometric gesture performed on the account holder’s hardware device, binding the specific action to the specific human?

The field travels with the transaction into the existing fraud engine. Nothing else in the engine changes. The models do not get retrained. The rules do not get rewritten. The engine just gets one more input — a deterministic one.

For the anatomy of the underlying receipt, see Cryptographic Receipts for Financial Transactions.

How Decisions Sharpen

The effect of the binary field on an existing fraud decision engine is asymmetric and favorable:

When the field is true

The engine has cryptographic confirmation that the action was authorized by the specific human on the specific device at the specific moment. Probability mass that was previously held back out of caution (“this looks mostly normal but we can’t be sure”) can move confidently toward “legitimate.”

The practical result: false-positive rates drop. Customers see fewer friction prompts on legitimate activity. Bank analyst teams spend less time reviewing clean transactions that were flagged because the probability signal was ambiguous.

When the field is false

No valid signature was produced for an action that required one. The decision is deterministic before the probabilistic model runs. The request fails at the signature-verification layer — outside the fraud engine entirely.

The practical result: the entire class of attacks that rely on credential theft, session hijack, or device takeover is closed at the perimeter of the fraud engine, not inside it. The engine never needs to decide whether a session-hijacked transfer “looks” suspicious, because the hijacked session cannot produce the binary field.

When the field is missing (APP fraud)

In the APP fraud case, the customer is manipulated into signing a real transfer to a criminal account. The biometric is real; the field is true. The probabilistic model still has to assess intent — and the primitive alone does not solve intent.

What authorization infrastructure adds in this case is a different artifact: a cryptographically-linked consent screen the customer signs, naming the payee and the amount and any scam warnings. This becomes an input to the fraud engine’s friction layer, and a non-repudiable record for any later dispute. For the APP-specific case see APP Scam Fraud: Why OTP and Risk Scoring Can’t Stop It.

Integration Shape

The integration is deliberately shallow. Authorization infrastructure ships three components and none of them replaces anything in a typical bank fraud stack:

  • Mobile SDK — a few lines of code into the customer-facing app (Android and iOS). Generates a hardware-bound key pair in StrongBox / Secure Enclave at enrollment. Produces an ES256 signature over a canonical action payload when the user performs a fresh biometric gesture at signing time.
  • Server-side verify — a verification step inside the existing bank endpoint that already handles the action (transfer, approval, export). Verifies the signature, checks the counter, rejects replay. Produces the binary field. Does not replace any existing authorization logic; it adds a gate in front.
  • Control plane — dashboard, cryptographic ledger of receipts, export to the bank’s data lake or SIEM, webhooks into the existing decision engine.

In every one of those components, the existing fraud stack remains in place and unchanged. The binary field becomes one more column in the event stream the fraud engine already consumes.

Who Loses Under This Model

If authorization infrastructure replaced fraud engines, the adoption curve would be a decade long — because fraud engines are deeply embedded, battle-tested, and carry organizational weight. Nobody rips out Actimize in a quarter.

Because authorization infrastructure composes with fraud engines instead, the adoption curve is a quarter, not a decade. Actimize, Featurespace, Sardine, and the incumbent behavioral-biometrics vendors all get sharper because of the primitive. The losers are not vendors — they are the specific attack classes that relied on identity uncertainty being the bank’s dominant source of error:

  • Account takeover.
  • Session hijacking (including modern AiTM toolkits).
  • Remote-access-trojan banking fraud.
  • SIM-swap-enabled transfers.
  • Credential-stuffing-enabled privileged actions.
  • Insider denial.
  • AI-agent-initiated actions without human approval.

The Correct Mental Model

A probabilistic fraud stack without a deterministic signal for human presence is compensating for a known unknown. Every scoring model in the stack carries a hidden penalty because it cannot directly observe whether the authorized human is authorizing the action. The penalty shows up as false positives (customer friction and analyst review load) and false negatives (successful ATO / RAT / session hijack / credential-stuffing attacks).

Authorization infrastructure does not remove the need for probabilistic reasoning. It removes the hidden penalty from the probabilistic reasoning. The fraud engine keeps doing what it was built for — behavioral analysis, graph analysis, risk scoring, adaptive rules — and now gets one more column that is binary and cryptographic and clean.

We are not the fraud stack. We are the deterministic signal the fraud stack was always missing.

Further Reading

← Back to Blog