Inspiration
The idea behind Incident Shield came from real-world PayPal fraud discussions I came across on Reddit.
I noticed people describing situations where unfamiliar payments appeared in their accounts, suspicious transactions were being processed through compromised accounts, and money was transferred to other accounts before the original payments could be investigated or reversed.
What caught my attention wasn't just the fraud itself. It was what happened afterward.
Victims were left trying to explain transactions, contact support, provide evidence and wait for investigations while the money could already have moved.
This made me question something fundamental:
What if a payment system could preserve the evidence and risk context at the exact moment a transaction occurred, so that when a complaint arrived, investigators wouldn't have to reconstruct everything from scratch?
I wanted to build something beyond another fraud-detection system: a solution that connects payment-time risk assessment, cryptographically preserved evidence, faster complaint investigation and human-controlled financial decisions.
That question became the foundation of Incident Shield.
What it does
Incident Shield is a fraud-protection and evidence-preservation layer designed around PayPal-style payments. It consists of two interconnected systems.
- Payment Protection and Evidence Preservation
Every payment is evaluated before capture using a risk engine containing 47 named signals across nine categories. Based on the risk assessment, a payment can be allowed, require payee confirmation, be delayed with a scam warning, held for review or blocked.
Every decision is preserved in a cryptographically sealed snapshot using AES-256-GCM encryption, HMAC-SHA256 signatures and SHA-256 hash chaining.
When a customer later reports an unauthorized payment or an authorized scam, the complaint is evaluated against the original payment-time evidence rather than relying only on the information available during the investigation.
A human reviewer makes the final decision, and approved refunds are processed through the PayPal sandbox refund API. The time between complaint and refund is also measured.
- Money-Mule Detection and Incident Intelligence
The second system monitors PayPal business-account webhooks and identifies suspicious money-mule patterns using deterministic rules.
It detects combinations of payment probes, bursts of incoming payments and rapid outgoing transfers, grouping related activity into incidents with an append-only audit trail.
An AI Copilot helps reviewers investigate incidents by explaining transaction patterns, summarizing available evidence and answering questions about suspicious activity.
The central principle is that AI never controls financial decisions. It cannot independently approve payments, block transactions, change risk scores or authorize refunds.
How we built it
I built Incident Shield using Python, FastAPI, a database-backed architecture, PayPal sandbox APIs and Gemini integration.
The payment protection system uses a custom risk engine with 47 named signals, weighted scoring, category caps, combination floors and trust adjustments. Evidence is collected from the application's own transaction ledger and browser measurements.
For evidence preservation, I implemented encrypted snapshots, HMAC signatures and SHA-256 hash chaining. Each snapshot records the information available when the payment decision was made, allowing its integrity to be checked later.
The payment workflow integrates PayPal Orders v2, payment capture and refund APIs. I also implemented idempotency controls to prevent duplicate payment or refund operations during retries.
For incident monitoring, I developed a webhook pipeline with request-size limits, rate limiting, PayPal signature verification, duplicate-event protection and merchant validation.
The money-mule detection system uses deterministic rules and sequence detection rather than allowing an AI model to independently classify financial activity.
The Gemini-powered Copilot operates within strict boundaries. It produces structured interpretations that are checked against facts constructed by the application. Invalid or unsupported responses are rejected, with deterministic template responses available as a fallback.
I also implemented reviewer permissions, expiring access keys, two-person approval for larger refunds, audit logging, operational metrics, reconciliation endpoints and a documented threat model.
The application is integrated with real PayPal sandbox APIs and is explicitly prevented from connecting to live PayPal payment hosts.
Challenges we ran into
- Preserving payment-time evidence
One of the biggest challenges was ensuring that a later investigation could access the original risk assessment rather than relying on changing account information. I addressed this using cryptographically sealed snapshots and hash chaining.
- Preventing AI hallucinations
Language models can generate convincing explanations containing incorrect numbers, transaction details or conclusions. I implemented structured outputs, deterministic validation, restricted inputs and fallback responses. I also learned that passing automated validation does not guarantee that an interpretation is semantically correct.
- Distinguishing suspicious activity from legitimate business behaviour
A sudden increase in incoming payments or rapid outgoing transfers does not automatically indicate fraud. I developed sequence-based detection rules to identify combinations of suspicious behaviour instead of treating individual rule hits as proof.
- Balancing fraud prevention and legitimate payments
Testing exposed a significant weakness in my risk engine. On a held-out set of 160 simulated fraud cases, the engine failed to stop any of them. This demonstrated that a sophisticated scoring architecture does not automatically translate into reliable real-world fraud detection.
Rather than hiding this limitation, I kept it visible and documented the results. Improving generalization is one of my most important future research directions.
- Integrating financial workflows safely
Handling payment capture, webhook retries, duplicate events, refunds and reviewer permissions required careful separation of responsibilities. I implemented idempotency controls, audit trails and additional approval requirements for larger refunds.
Accomplishments that we're proud of
- Built a payment risk engine containing 47 named signals across nine categories.
- Implemented cryptographically sealed payment decisions using AES-256-GCM, HMAC-SHA256 and SHA-256 hash chaining.
- Integrated real PayPal sandbox order, capture, refund and webhook APIs.
- Implemented a complaint investigation workflow that evaluates complaints against original payment-time evidence.
- Built deterministic money-mule detection with sequence-based incident grouping.
- Developed a constrained AI Copilot with fact validation and deterministic fallback responses.
- Implemented reviewer roles, two-person refund approvals, expiring credentials and append-only audit logging.
- Created operational monitoring, reconciliation endpoints, a threat model and documented deployment and recovery procedures.
- Verified all 12 test webhook signatures successfully during sandbox testing.
What I am particularly proud of is the separation of responsibilities. I didn't build an AI system that gets unrestricted authority over financial decisions. I built a system where evidence, deterministic code and human oversight remain central.
What we learned
Building Incident Shield changed how I think about applying AI to financial systems.
I learned that a reliable AI-powered application requires much more than connecting a language model to an API.
It requires carefully defined permissions, deterministic validation, secure data handling, failure management and a clear understanding of what the AI should never be allowed to do.
I also learned the importance of distinguishing between simulated results and real-world performance. Synthetic benchmarks can help evaluate implementation logic, but they cannot establish actual fraud-detection accuracy.
Another important lesson was that missing information must remain explicitly missing. A system should never interpret unavailable identity, card or geolocation information as proof that a transaction is safe.
Most importantly, I learned that financial security is not just about detecting suspicious activity. It is about preserving evidence, making decisions accountable and ensuring that people retain control over their money.
What's next for Incident Shield
My next priority is improving the reliability and generalization of the risk engine.
I want to move beyond author-defined simulated datasets and evaluate the system against more diverse, appropriately labelled fraud scenarios.
Some of the areas I want to explore include:
- Improving risk scoring through better evaluation and more representative labelled outcomes.
- Expanding detection of account takeovers, authorized scams and sophisticated money-mule networks.
- Improving payment-time evidence collection and cryptographic verification.
- Strengthening AI validation and testing for adversarial inputs.
- Improving incident investigation and reviewer workflows.
- Conducting independent security testing and evaluating production-readiness requirements.
- Exploring how the system could integrate with larger payment platforms.
Incident Shield is currently a sandbox prototype. It does not implement KYC/AML, settlement, chargeback handling or independent external security certification. Several risk signals are simulated or unavailable, and its fraud benchmarks are not representative of real-world performance.
My long-term vision is to develop Incident Shield into a reliable evidence-driven fraud investigation and payment-protection layer that could complement existing financial platforms.
AI explains. Evidence decides. Humans authorize.
Built With
- aes-256-gcm
- ai
- api
- configurable
- fallback
- fastapi
- gemini
- hmac-sha256
- neon
- postgresql
- pytest
- python
- render
- sha-256-authentication-api-keys
- sqlalchemy
