LynxPay

Protecting the intent behind every payment

LynxPay is an AI-powered pre-payment security layer that detects socially engineered digital payments before authorization. Traditional fraud systems ask whether the device, account, pattern and beneficiary look suspicious. LynxPay adds one more question: does this payment still reflect the user's genuine, uncompromised intent?

How a decision is made

Each payment runs through six independent engines: language & intent AI, intent-to-transaction consistency, behavioural anomaly detection, beneficiary-graph risk, and a transparent transaction-rule engine. Their scores are combined by a weighted fusion model (40% language + intent, 20% behaviour, 20% graph, 20% rules). Mandatory safety policies can escalate, but never soften, the outcome. The result is one of four decisions: Allow, Warn, Step-up verify or Block.

The AI model

Only the language & intent stage uses a large language model, and its role is deliberately narrow: read a message or call in the user's own language (English, Hindi, Tamil, code-mixed Tanglish/Hinglish, Bengali, Marathi and Telugu), extract what the user believes they are paying for, and flag social-engineering signals. It returns structured evidence, never a verdict.

The model layer is swappable by configuration, so the same code runs three ways:

Indian multilingual LLM (Sarvam) for the live configuration, the right fit for India-first, code-mixed language.
Self-hostable in-house model (a fine-tuned MuRIL / open-weights model) on the production path, so payment data never leaves India: a DPDP and RBI-aligned sovereignty edge.
Deterministic offline fixture for demos, so the walkthrough can never fail on venue wifi.

Whichever model runs, the decision is made by a transparent policy, not the model. The provider and model version are recorded on every assessment and shown in the analyst console.

Responsible AI

AI supports the risk assessment but never independently executes payments.

Final decisions are governed by transparent, deterministic policies, not the model alone.

Every model finding is evidence-backed and traceable to the supplied context.

Risk indicators show elevated risk but do not by themselves prove fraud.

Users always receive clear reasons and a safe next step.

Human analysts can override any decision, with the reason recorded in the audit trail.

Prompt, rule, model and fusion versions are recorded on every assessment.

All data is synthetic; no real customer, bank, UPI or device data is used.

Multilingual understanding is best-effort and has known limitations.

False positives are measured against a labelled evaluation set.

Sensitive identifiers such as UPI handles and phone numbers are masked.

Production integration would require explicit user consent and regulatory review.

This is a synthetic demonstration environment. It uses generated payment, message, call, QR and beneficiary data and does not connect to any real UPI, NPCI, bank, telecom, SMS/WhatsApp, device or remote-access system. Detailed documentation lives in the repository's docs/directory (architecture, threat model, privacy, responsible-AI, model card, evaluation).