Benny: More Perks. Less Fine Print.

Your AI companion that finds forgotten credit card perks, picks the best card at checkout, and uncovers protections for purchases you’ve already made.

Comment

Overview

Credit cards have become bundles of financial products: rewards programs, monthly credits, purchase protections, extended warranties, and merchant-specific perks. Yet using those benefits still requires people to connect information scattered across banking apps, receipts, emails, and lengthy policy documents.

We built Benny to bring those pieces together. Benny connects what you bought, which card you used, and the relevant card terms to help answer three questions: What did I earn? What could I have earned? What benefits might I be missing?

Our central engineering principle is “agents propose, evidence decides.” AI interprets unstructured documents; deterministic logic performs calculations and checks supported conditions. This separation lets Benny provide useful recommendations without treating a plausible model response as financial proof.

Built by a two-person team during the hackathon, Benny brings this architecture into a working application built and hosted on Mana.

Inspiration

We’ve all reached for the wrong card at checkout or discovered a perk after it expired. But choosing the best cashback rate is only one part of the problem.

A purchase can also carry protections that become valuable months later. A broken appliance might qualify for extended warranty coverage. A subscription might qualify for a monthly credit, but only after enrollment. Those benefits are difficult to use because the purchase history, item details, and eligibility conditions rarely live in the same place.

We wanted to build something that goes beyond recommending another card. Benny helps people understand and use the cards they already carry.

What it does

Benny supports the moments before and after a purchase:

  • Before paying: Compare estimated rewards across selected cards and see which card is better suited to the purchase category.
  • After paying: Review estimated rewards earned and identify purchases where another card in the wallet could have earned more.
  • Between purchases: Discover available credits, activation requirements, and supported protections through an interactive card wallet.
  • When something goes wrong: Review potential purchase protections and, when required facts are confirmed, generate a claim draft.

Users can start by selecting cards and uploading a receipt or order email, without first connecting a bank. Plaid transaction ingestion, Gmail receipt discovery, and supported statement uploads provide additional purchase evidence.

Benny keeps hypothetical comparisons separate from actual card ownership, and estimates separate from confirmed evidence. It helps users investigate an opportunity without presenting that opportunity as a guaranteed payout.

How we built it

Building end to end with Mana

Mana was our development environment throughout the project, from brainstorming and combining two early prototypes to building the interface, backend, integrations, and shareable application.

We iterated through conversation and screenshots, changing the working product rather than maintaining disconnected mockups. One important example was the receipt flow: we moved from requiring a bank match first to showing immediate card-by-card estimates, with paying-card confirmation as a separate step.

This let us improve the product’s behavior, not just its appearance, while keeping frontend and backend changes connected.

Evidence pipeline

Benny combines a React interface, Python API, and SQLite database. Its processing flow separates document interpretation from financial decisions:

Receipt, email, or statement → structured purchase details → validation and matching → reward and benefit evaluation → user-facing findings

Gemini extracts purchase information from unfamiliar receipt and email layouts. The application validates structured outputs and retains evidence about the source and confidence of relevant facts.

Bank transactions and receipts play different roles. A transaction helps establish payment history; a receipt adds item-level detail. Neither automatically proves everything needed for a benefit decision.

Deterministic rewards engine

Reward calculations run in a separate rules engine rather than being generated by an LLM.

The engine compares supported earning rates across cards, accounts for available merchant-category information, and distinguishes cashback from points whose cash value depends on redemption assumptions. Conditional rates are surfaced separately rather than automatically counted as earned.

This makes the arithmetic reproducible and allows us to test decision logic independently of document extraction.

Source-backed card rules

The card-rule pipeline retrieves issuer material and extracts structured rules with source URLs and quoted terms. A quote-verification step checks that accepted quotations appear in the retrieved source text.

The current pinned catalog contains 21 card products. Versioned rule and engine snapshots, together with integrity checks, give the shared app a consistent calculation foundation.

Importantly, verifying that a quote exists does not prove that a user qualifies. Missing purchase details, exclusions, and unresolved conditions still require confirmation.

Private purchase records

The application is shareable, but users’ purchase records are not shared with it.

Private records remain behind the Python API, where requests are authenticated and database queries are scoped to the signed-in user. Plaid access tokens remain encrypted on the server rather than being exposed to the interface.

We also built cross-user isolation tests to check that one user cannot retrieve or modify another user’s records.

Challenges we ran into

Connecting incomplete evidence

A merchant name is not an item description, and an item description is not proof of payment. Matching receipts to transactions required handling differences in dates, merchant formatting, amounts, and available payment identifiers.

We had to preserve ambiguity rather than force every document into a confident match.

Preventing misleading totals

The same purchase can arrive through a bank connection, statement upload, and receipt. Counting each source independently would inflate spending and rewards.

We implemented duplicate-handling logic and separated cards users actually hold from cards they are only trying. Otherwise, a hypothetical comparison could incorrectly influence the user’s reported rewards.

We also encountered non-purchase financial emails that resembled order confirmations. That reinforced the need to classify documents before treating them as spending.

Interpreting benefits responsibly

Benefit terms contain enrollment requirements, spending caps, exclusions, and timing conditions. Retrieving a policy is easier than correctly applying it.

We designed Benny to expose supported conditions and missing information instead of letting AI turn incomplete evidence into a coverage promise.

Keeping the experience approachable

The underlying system needs detailed evidence, but the user should not have to navigate a database to understand a card.

We organized the interface around an interactive stacked wallet, concise summaries, source-linked details, and a separate review flow. The visual identity draws from banknote engraving, with a cream-and-green palette, guilloche rosette, and light and dark modes.

Accomplishments that we're proud of

  • Building a connected product: Card comparison, receipt intake, benefit discovery, spending analysis, and claim drafting share one application and evidence model.
  • Separating AI interpretation from calculation: Gemini handles messy inputs while explicit logic controls reward arithmetic and supported checks.
  • Making receipts useful immediately: Users can explore potential rewards before completing a bank connection.
  • Making uncertainty visible: Estimates, assumptions, and missing details are part of the experience rather than hidden implementation details.
  • Building for multiple users: Shared access to the app does not mean shared access to private purchase records.
  • Taking the project from idea to execution: Mana helped our two-person team brainstorm, prototype, implement, debug, and refine the same working app throughout the hackathon.

What we learned

Building Benny taught us that the hardest part of financial AI is not producing an answer. It is establishing what that answer is allowed to mean.

Document extraction, payment matching, reward calculation, and benefit eligibility are different problems. Treating them as separate layers made the application easier to reason about, test, and explain.

We also learned that source traceability is necessary but insufficient. A quotation can be authentic while its application to a particular purchase remains uncertain.

Finally, we learned that product design and system architecture influence each other. Letting users start with a receipt was not simply an onboarding change; it required separating hypothetical rewards from confirmed payment history throughout the system.

What's next for Benny: More Perks. Less Fine Print.

Our next steps are to expand card coverage, strengthen policy-version tracking, and improve matching for difficult cases such as split payments, refunds, and wallet-specific payment identifiers.

We also want to add opt-in reminders for expiring credits and benefit deadlines, and improve claim preparation while keeping every submission under the user’s control.

Longer term, we want Benny to help people evaluate the cards they already carry using their actual spending and benefit usage, rather than headline reward rates alone.

Our goal is not to encourage more spending. It is to make the value of existing spending easier to understand and use.

Mana Specific Guidelines

01 Write one paragraph

Mana was our end-to-end building environment for Benny, helping us take the project from our first brainstorm to a working, shareable app in one continuous experience. We used it to sharpen the idea, scope features, prototype user flows, and build both the interface and backend through conversation. It helped us integrate Gemini for receipt reading, implement receipt and statement uploads, connect Plaid Sandbox/Production for transaction testing, and build the logic that turns card benefits into actionable insights about unused credits, missed rewards, and purchase protections. Beyond generating code, Mana helped us work through architecture, private per-user storage, evidence-backed calculations, debugging, and testing. We refined everything from onboarding to our interactive card wallet and dollar-bill-inspired visual identity by sharing screenshots, describing changes, and seeing them live in the same app. Its built-in infrastructure kept us from spending the hackathon stitching together separate tools and deployment workflows, giving our two-person team more time to focus on the product. Mana did not just help us build a prototype; it let us carry an idea through design, implementation, testing, and sharing without leaving the workspace.

02 Link the proof

03 Demo one moment

Built With

Share this project:

Updates

Submission history