Upay Compass

The problem

Many people who use a mobile wallet (students, gig and informal workers, first-time savers) can see their transactions but cannot easily tell where their money goes, whether they can afford something next week, or how to start saving. Advice is usually in English, generic, and not tied to their own numbers.

Upay Compass was built for the DIU CPC × upay AI Hackathon 2026, Track 03 (Customer Innovation & Financial Independence). It turns wallet transactions into plain-language insight and guidance, in Bangla and English.

The rule: AI for language, code for numbers

Language models write explanations and understand speech. Every figure is computed or checked by deterministic, unit-tested code: balance, scores, the forecast, the "can I afford this?" verdict, and the amounts in a spoken command.

That rule decides what each model is allowed to do.

• Coach. Explains a summary of the person's numbers in their language. It gets no phone number, name, merchant names or transaction list, and the affordability verdict comes from code. Without the AI it falls back to a template answer.
• Categorization fallback. Rules run first: the person's own corrections, then a channel and keyword map. The model only sees merchants the rules cannot place, only if the person has agreed to share data, and it can only return a category from the allowed list. Anything else becomes "Other, needs review".
• Voice commands. The model turns one sentence into a typed command under a strict JSON schema. It never chooses the amount.
• Speech to text and text to speech. Used only when the browser has no speech recognition or no voice for the language.

Health score, credit readiness, forecast, unusual-payment detection, nudges and learn ranking involve no AI at all.

Voice commands

A person can add or remove a payment, set a budget, create a goal, add to a goal, or ask the coach, just by speaking. The hard part is trusting a model with money, so the flow is built around not trusting it.

The model proposes a command. Code then checks that the amount is a number the person actually said, and resolves the date, category and goal itself. The result appears on an editable card, and nothing is written until the person taps Confirm. The same hooks that power the manual forms then run it, and Undo is available afterwards.

The voice parser has a golden-set evaluation, including a holdout of unseen sentences, that fails if a single wrong amount is accepted.

What it does

• Dashboard and transactions. Balance, income and spending by period, category breakdown, weekly chart, searchable payment list, and a "repeat a recent payment" shortcut.
• Budgets and goals. Monthly category budgets with alerts, savings goals with projected finish dates, optional round-up saving.
• Financial health score. 0 to 100 from savings rate, budget adherence, cash buffer and income stability, with plain "what to improve" actions.
• Credit readiness. An informational scorecard, explicitly not a credit decision, with the steps that would raise it.
• 30-day forecast. Detects recurring income and bills, projects the balance, and flags days it may drop below a safety buffer. It is backtested against a naive baseline.
• Unusual-payment alerts. Flags payments far above a merchant's normal amount, with a plain explanation.
• Learn, streaks and badges. Short financial-literacy modules in both languages, ranked by the person's own situation.
• Installable PWA that works offline for reading the last-saved data, with light and dark themes.

Architecture

The frontend is Next.js 16 with React 19 and Tailwind CSS 4, using TanStack Query, i18next for English and Bangla, and Recharts. The backend is Supabase: Postgres with row level security on every table, phone OTP auth, Realtime, and Edge Functions on Deno. All model calls are made from Edge Functions, so the OpenAI key never reaches the browser.

Business logic lives in a shared, pure TypeScript package used by both the app and the functions, so the same tested code computes a score on the client and on the server.

There is no live upay system to connect to, so the app reads transactions through a pluggable TransactionFeed contract. A simulator, a CSV statement import and a partner-API adapter built against an assumed API all plug into the same pipeline. Real upay data can be connected without changing the app.

Privacy and security

• Sending data to OpenAI needs the person's consent, separately for the coach and for voice.
• Every model call is rate limited and audited without storing what was said.
• The app PIN is hashed on the server, with backoff from 30 seconds to 15 minutes on wrong tries. Fingerprint and face unlock use passkeys.
• People can download everything the app holds about them, or delete their account, from the profile screen. Short-lived data is purged on a schedule.
• A black-box probe of 170 security checks runs against the local stack, covering function auth, cross-user access, PIN lockout, rate limits and malformed bodies.

Testing and evaluation

Beyond unit and integration tests (including row level security), the repo has evaluations for voice parsing, a 16-question coach evaluation covering grounded figures, guardrails and prompt secrecy, unusual-payment detection against the old flat rule, a fairness audit of scores across three simulated personas, and a scan of the production build for leaked secrets.

Limits

All transaction data is simulated or entered by the user, and no real money moves. The guidance is educational, not financial, credit or investment advice. Bangla speech recognition and read-aloud were tested with synthesized speech and still need a check on real devices.