SANDI — AI Card Savings Concierge

SANDI turns each purchase—what, where, when, and how much—into an explainable savings plan, using your existing cards before suggesting a new one.

Comment

Inspiration

Built in New York City during OpenAI Build Week, SANDI began with a simple frustration: earning the best credit-card reward should not require five bank pages, a spreadsheet, and mental math at checkout.

The right choice changes with the merchant, category, location, purchase amount, spending threshold, offer period, and cards already in a person’s wallet. Most comparison tools begin by promoting another card. We wanted to reverse that logic: help people get more value from the cards they already have, then surface a new card only when it creates clear additional value.

What it does

SANDI is a mobile-first, location-aware AI card-savings concierge.

Users add the card products they already hold—never bank credentials or full card numbers—then describe a purchase in everyday language . For example: “I need dinner nearby tonight. Which card should I use?”

SANDI then:

  • Extracts the purchase category, merchant, location, amount, and timing.
  • Searches for relevant nearby places and eligible offers.
  • Compares the cards already in the user’s wallet.
  • Explains the best option, estimated savings, thresholds, and alternatives.
  • Switches between a text explanation and a map with reward-aware merchant markers.
  • Keeps “best card I already own” separate from “possible new-card opportunity.”
  • Helps users plan larger future purchases when card timing may matter.
  • Tracks benefits, reminders, and upcoming spending plans in one experience.

The public build is a working prototype using sample card benefits and offer data. It does not connect to bank accounts, submit card applications, determine credit eligibility, or complete reward redemption.

How we built it

We designed SANDI as a hybrid AI-and-rules system so natural-language understanding could remain flexible while financial comparisons stayed inspectable.

The mobile interface uses React 18, JavaScript, Babel, plain CSS, Leaflet, and MapLibre. It supports wallet management, text and browser-based input, recommendation results, nearby exploration, future-purchase planning, and a text-to-map answer mode.

The backend uses Python and FastAPI with SQLite and RTree spatial indexing. It handles structured offers, nearby-place search, data imports, recommendation audits, and location and walking-route adapters. Our local data layer indexes more than 300,000 urban points of interest, while the public GitHub Pages version falls back to a smaller bundled sample so judges can explore the core experience without running the backend.

In connected mode, GPT-5.6 uses the OpenAI Responses API and a strict JSON schema to turn free-form requests into structured intent. It identifies fields such as category, merchant, location, amount, and timing. A deterministic policy engine then calculates and ranks the available options. If the OpenAI service is unavailable, SANDI falls back to a local rule-based parser.

We used Codex throughout OpenAI Build Week as an engineering partner: turning product requirements into scoped implementation plans, building and refining the React and FastAPI flows, investigating edge cases, generating tests, and verifying the browser experience. This helped us iterate quickly without losing clear product and system boundaries.

Challenges we ran into

The hardest challenge was deciding what AI should—and should not—control. A language model is useful for understanding an ambiguous request, but card calculations need reproducible rules. We limited GPT-5.6 to structured intent extraction and kept eligibility checks, savings calculations, and ranking in deterministic code.

Location data created another challenge. Nearby recommendations depend on coordinate systems, distance calculations, data quality, and source provenance. We added coordinate normalization, spatial indexing, quality checks, source metadata, and graceful fallbacks instead of treating every location result as equally certain.

We also had to keep two very different recommendations from becoming one confusing answer. SANDI always ranks the user’s existing cards first. Potential new cards live in a separate layer and must demonstrate incremental value rather than replacing the organic result.

Finally, we needed to build a convincing demo without presenting it as a finished financial product. A production launch will still require verified issuer and merchant terms, secure identity and consent controls, offer-version tracking, and formal data partnerships.

Accomplishments that we're proud of

We are proud that SANDI became an end-to-end, usable prototype rather than a collection of disconnected screens. A user can describe a purchase, receive an explainable recommendation, inspect nearby alternatives on a map, and continue into future-purchase planning.

We are also proud of the system’s transparency. Recommendation records preserve the parser source, model, policy version, request, and result, making it possible to understand how an answer was produced.

The prototype supports both a connected, data-backed mode and a resilient public demo mode. Tests cover intent parsing, recommendation logic, imports, spatial behavior, database migrations, and route integration.

Most importantly, we preserved the product principle that started the project: help users save with what they already have before suggesting anything new.

What we learned

We learned that the strongest role for AI in a financial utility is translating messy human language into clear structure—not hiding important calculations inside a black box.

We also learned that location is not merely a map feature. It changes which merchants are practical, which offers apply, and whether a recommendation is useful at that moment.

Trust comes from details that are easy to overlook: showing thresholds, separating estimates from verified facts, exposing data provenance, and explaining why an option won. In this category, compliance and transparency are part of the user experience.

Finally, Codex showed us how quickly a product can evolve when planning, implementation, testing, and documentation remain in the same working loop.

What's next for SANDI

Our next step is a tightly scoped New York City pilot covering nearby dining and a small set of everyday spending categories with verified, versioned U.S. issuer and merchant terms.

Before any production launch, we plan to add secure authentication, explicit consent controls, encrypted storage, retention and deletion policies, stronger access control, and direct links to official offer terms. We also want to measure the complete savings loop—from recommendation to confirmed redemption—without collecting unnecessary financial data.

Longer term, SANDI could expand across cities, support more languages and card programs, and become an issuer-neutral savings layer that helps people make better use of the cards already in their wallets.

Built With

Share this project:

Updates