SikaGuard: Verify Before AI Pays

Inspiration

AI agents are rapidly moving from answering questions to taking actions on our behalf, including making purchases, comparing financial products and potentially committing users to credit agreements.

But this raises a fundamental security question:

What happens when an AI agent has permission to spend your money, but the information influencing its decision is misleading?

Traditional spending limits can prevent unauthorised transactions, but they cannot necessarily detect manipulated merchant claims, hidden repayment obligations, or discrepancies between what a customer expects and what a financial agreement actually requires.

I built SikaGuard to explore the gap between payment authorisation and informed financial consent.

Capital One's Make Credit Secure challenge inspired the consumer-protection focus, particularly the need to prevent digital payment scams. Telluvian's parallel-AI challenge motivated the research question: can multiple specialised AI systems identify financial risks that a single model or deterministic controls might miss?

What it does

SikaGuard is a security firewall for autonomous AI purchasing agents.

Before a proposed transaction proceeds, it evaluates the customer's spending mandate, the selected financial product, merchant representations, and available supporting evidence.

The system produces three possible outcomes:

  • ALLOW: The transaction satisfies the applicable financial and authorisation controls.
  • REVIEW: A verified material discrepancy or independently defined evidence requirement needs human attention.
  • BLOCK: The transaction violates a deterministic authorisation rule.

Its central design principle is:

AI investigates. Trusted code verifies. Financial rules remain in control.

Instead of giving a language model authority over payments, Sika Guard uses three concurrently executing, prompt-specialised analysts:

  1. Merchant Claims Analyst: investigates potentially misleading merchant representations.
  2. Credit Terms Analyst: examines financing disclosures, repayment obligations and hidden charges.
  3. Delegated Authority Analyst: examines potential conflicts with the customer's authorised permissions.

The analysts generate candidate findings and structured evidence extractions. Trusted code then checks source references, quotations, amounts, contractual scope, financial materiality, and authorisation constraints.

A model's verdict alone cannot block a transaction or override a deterministic decision.

How I built it

I implemented SikaGuard's security engine in Python, using Pydantic for strict data contracts, HTTPX for LLM API integration, and pytest for automated regression and adversarial testing.

I integrated Telluvian's API with GPT-4o-mini for recorded live inference and developed six experimental configurations:

Condition Configuration
A Deterministic rules
A+ Deterministic rules and text scanning
B Single general-purpose AI analyst
B3 Three concurrent generalist analyses
Bc Single generalist with a combined specialist rubric
C Three concurrent, prompt-specialised AI analysts

All configurations use the same trusted financial verification and enforcement policy.

I also implemented source-provenance checks, recorded inference evidence, reproducible evaluation manifests, sealed experimental logs, and safeguards against unsupported AI allegations.

The published backend passed 1,028 automated tests, independently reproduced from the GitHub repository.

For the interactive demo, I built a responsive application using React, TypeScript, Vite and Tailwind CSS, deployed through Netlify.

It lets visitors explore legitimate transactions, mandate violations, and financial discrepancies, then examine the AI evidence trail and recorded experimental comparisons.

The demonstration

One of the most important experiments involved a financing agreement whose lender document contained a mandatory £32 credit-file assessment charge, while the structured financial terms recorded no such charge.

Condition A, which only evaluated structured data, returned ALLOW.

Under Condition C, the credit-terms specialist extracted the charge and its supporting quotation. Trusted code verified the source and established that the lender's document conflicted with its structured terms.

The transaction was escalated to REVIEW.

However, our deterministic text scanner, A+, also detected the same discrepancy.

This demonstrates a functioning AI-assisted evidence-verification pathway, not that parallel AI outperforms deterministic scanning.

That distinction became central to the project.

Challenges I faced

AI confidence is not correctness

Models sometimes confidently alleged financial violations that were mathematically false, even when their responses followed the required schema.

I addressed this by separating AI-generated assessments from deterministic arithmetic, mandate enforcement and evidence verification.

Extracting evidence instead of opinions

Early model responses recognised potentially important financial charges but expressed them only as general concerns. They did not return structured, verifiable claims.

I revised the extraction contract so models could identify financial statements with explicit quotations, source references and amounts, without granting their interpretations independent enforcement authority.

Preventing fabricated evidence

Some model responses cited invalid document references or incorrectly attributed financial statements.

Sika Guard rejects unsupported extractions instead of silently repairing them or allowing them to influence the transaction decision.

Evaluating parallel AI fairly

Perhaps the biggest challenge was distinguishing genuine AI capability from benefits already available through ordinary deterministic software.

I built the A+ baseline specifically to test this. In the recorded live cases, parallel AI did not demonstrate incremental interception beyond A+.

Preserving this negative result was important to making the research credible.

Reproducibility

Security testing revealed problems involving source authority, timestamps, mandate semantics, financial quantities and experimental integrity.

I addressed these through targeted regression tests, adversarial reviews and reproducible saved results.

What I learned

Building Sika Guard reinforced several lessons:

  • A correctly formatted LLM response can still be financially wrong.
  • Agreement between multiple models is not independent evidence.
  • Parallel execution does not automatically mean better security.
  • Unnecessary transaction reviews can themselves harm customers.
  • Financial authorisation must remain independent of probabilistic model recommendations.

Most importantly, the challenge is not simply making AI more capable; it is establishing which AI-discovered facts can actually be trusted.

What's next?

Sika Guard is currently a synthetic, sandbox-only research prototype, not a production payment service.

Next, I want to investigate:

  • Frontier OpenAI and Anthropic models for more reliable financial-document understanding.
  • Semantic extraction of obligations spanning multiple sentences and conditional clauses.
  • Independently labelled benchmarks measuring genuine improvement beyond deterministic controls.
  • Adaptive routing between specialised models to balance reliability, latency and cost.
  • Authenticated lender evidence, verifiable mandates and integration with real financial authorisation systems.

Longer term, this research could contribute to SikaHub, my wider work on accessible and interoperable financial infrastructure.

As AI agents increasingly handle financial decisions, users will need systems that check not just whether an agent can spend their money, but whether the proposed transaction reflects what they actually intended.

SikaGuard: Verify Before AI Pays.


Try the project

Interactive demo: https://sikaguard.netlify.app/

Source code: https://github.com/pkaysantana/SikaGuard

Built at HackNotts 2026 for Capital One's Make Credit Secure challenge and Telluvian's parallel-AI challenge.

All transactions, customer profiles, and financial documents are synthetic. No real payments are executed.

Built With

Share this project:

Updates

Submission history