TransferGuard

TransferGuard is a safety layer for high-consequence financial actions that uses AI to understand intent, evidence to verify it, and deterministic policies to prevent unauthorized transfers.

Comment

Inspiration

Payment fraud is a large and persistent problem across organizations.

The 2025 AFP Payments Fraud and Control Survey reported that 79% of surveyed organizations experienced attempted or actual payments fraud in 2024. Business email compromise was identified as a leading avenue for payments fraud attempts, along with vendor impersonation.

The FBI's Internet Crime Complaint Center has reported that Business Email Compromise resulted in more than $55 billion in exposed losses from reported incidents between October 2013 and December 2023.

The ACFE Report to the Nations also analyzes thousands of real occupational-fraud cases across countries and industries, showing the significant financial impact of fraud and the importance of organizational controls.

But we didn't want to build another fraud predictor.

A payment can be unusual and completely legitimate. At the same time, a normal-looking payment can become dangerous because of one changed detail, such as a beneficiary account or an attempt to bypass authorization.

That led us to a different question:

Before a consequential financial action happens, do we actually have enough evidence to authorize it?

That question became TransferGuard.

What it does

TransferGuard is a pre-transfer safety layer for consequential financial actions.

A user can enter a payment instruction in natural language:

"Please urgently pay Acme Supplies $480,000 for invoice INV-8841. They sent updated banking details this morning."

TransferGuard uses AI to understand the instruction and extract:

  • Vendor
  • Amount
  • Currency
  • Invoice
  • Purchase order
  • Urgency
  • Beneficiary information
  • Safety-relevant signals

It then separates the AI's interpretation from authoritative evidence and evaluates the transaction against organizational policies.

The result is one of three decisions:

ALLOW

The required evidence and authorization are present.

VERIFY

The transaction may be legitimate, but a specific unresolved condition requires human confirmation.

BLOCK

Critical requirements are missing, contradictory, or violate an active policy.

The important part is that the AI does not make the final decision.

Our core principle is:

AI can understand. Evidence must authorize.

The workflow is:

Natural-language instruction
          ↓
      AI analysis
          ↓
   Structured intent
          ↓
 Evidence + Policy checks
          ↓
 Deterministic decision
          ↓
   ALLOW / VERIFY / BLOCK
          ↓
 Human verification if needed
          ↓
      Re-evaluation
          ↓
      Audit trail

TransferGuard can process transactions created by users rather than relying only on predefined examples.

How we built it

TransferGuard is a full-stack TypeScript application with a local AI layer.

AI Layer

We integrated Qwen3 4B through Ollama.

The model is used for:

  • Natural-language intent extraction
  • Entity extraction
  • Safety-signal identification
  • Evidence fact extraction
  • Cross-claim analysis
  • Natural-language policy conversion

The AI produces structured information, but it cannot directly authorize a transaction.

Evidence Layer

Evidence is represented as structured claims with provenance.

This allows us to distinguish between:

"The AI extracted that the invoice says $250,000."

and:

"Verified evidence establishes that the invoice amount is $250,000."

That distinction is fundamental when dealing with consequential actions.

Deterministic Decision Engine

The final decision is handled by a deterministic TypeScript engine.

It evaluates:

  • Transaction attributes
  • Evidence
  • Beneficiary consistency
  • Authorization
  • Organizational policies
  • Required verification
  • Conflicting claims

This means the same engine evaluates both seeded examples and completely new transactions created by users.

Platform

The application includes:

  • Transaction creation
  • AI-assisted intake
  • Evidence management
  • Policy management
  • Human verification
  • Decision explanations
  • Audit history
  • Persistent transaction state

Users can create transactions from scratch rather than only interacting with predefined scenarios.

Validation

TransferGuard was validated through end-to-end testing using dynamically created transactions, while its problem definition is grounded in real-world payment-fraud research from AFP, FBI IC3 and ACFE.

Our final validation included 5/5 core acceptance tests passing, including normal payments, beneficiary changes, unsupported payment directives, legitimate unusual transactions, and arbitrary user-created transactions.

Challenges we ran into

1. Deciding where AI should stop

The easiest architecture would have been:

Payment instruction → LLM → Safe / Fraud

We deliberately didn't do that.

For a consequential workflow, we wanted the AI to understand context without becoming the authority that decides whether an action can happen.

That forced us to design a clear boundary between:

AI interpretation → evidence → policy → decision

2. Handling legitimate unusual transactions

A system that blocks every unusual transaction can interfere with legitimate business.

An $8 million acquisition payment may be extremely unusual, but if the transaction has the appropriate acquisition agreement, board authorization, executive approval and beneficiary evidence, "unusual" alone shouldn't determine the outcome.

This is why VERIFY became a first-class state.

3. Moving beyond predefined demos

We didn't want TransferGuard to simply switch between four hardcoded scenarios.

We built the transaction creation workflow so users can create new transactions and send them through the same evaluation pipeline.

This was important because a safety platform should work on inputs it has never seen before.

Accomplishments that we're proud of

A real end-to-end workflow

A user can start with an unstructured financial instruction and take it through:

AI analysis → evidence → policy evaluation → decision → human verification → re-evaluation → audit trail.

AI with an explicit safety boundary

The AI can interpret and analyze, but it cannot:

  • Approve transactions
  • Override policies
  • Mark evidence as verified
  • Bypass authorization
  • Fabricate external verification

Explainable decisions

Instead of showing a black-box fraud score, TransferGuard can explain:

  • What evidence was found
  • What is missing
  • What conflicts
  • Which policy applies
  • Why verification is required
  • What action the user needs to take

User-created transactions

The system isn't limited to predefined transaction IDs or demo paths.

New transactions can be created and evaluated dynamically using the same decision engine.

Legitimate unusual transactions

Our system demonstrates that a high-value or unusual transaction doesn't have to be automatically treated as fraud when sufficient evidence and authorization exist.

5/5 Acceptance Tests Passed

Our final acceptance suite passed 5 out of 5 tests (100%), covering:

  1. Normal payment → ALLOW
  2. Beneficiary modification → VERIFY → human verification → ALLOW
  3. Unsupported payment directive → BLOCK
  4. Genuine unusual $8M transaction → ALLOW
  5. Arbitrary user-created transaction → dynamically evaluated

The AI intake workflow was also tested successfully for extracting transaction entities and safety signals.

What we learned

Our biggest lesson was that AI safety is often a system-design problem, not just a model problem.

A model can understand a financial instruction extremely well and still shouldn't have authority to execute its interpretation.

We also learned the importance of separating:

What the AI believes

from:

What the organization has established as evidence.

That distinction influenced almost every part of TransferGuard's architecture.

Finally, we learned that uncertainty doesn't always require a binary answer.

Sometimes the right decision is:

"This may be legitimate. We need one specific thing verified before proceeding."

That is why VERIFY is central to TransferGuard.

What's next for TransferGuard

TransferGuard currently operates in a synthetic financial environment. It does not move real money or contact external financial institutions.

The next step would be connecting the same safety architecture to real enterprise systems such as:

  • ERP systems
  • Procurement platforms
  • Identity and authorization systems
  • Vendor master systems
  • Payment infrastructure

We also want to expand the evidence layer so organizations can connect multiple authoritative sources and continuously reconcile the claims involved in a consequential action.

The long-term goal is to make TransferGuard an infrastructure layer that sits between intent and consequential execution.

The principle would remain the same:

AI can understand the action. Evidence, policy and authorized humans determine whether it can proceed.

Built With

Share this project:

Updates

Submission history