CreditPilot AI

Scenario 0 - Login Auth0
Scenario 1- Shortfall
Scenario 2 - Credit
Scenario 3 - AutoPay
Scenario 4 - Joint Accounts
Scenario 5 - Emergency Readiness

Inspiration

A laptop breaks the week before a deadline. Your bank balance looks sufficient to replace it. One credit card offers rewards, another has available credit—but rent is due in three days.

Can you actually afford the purchase?

As students, we recognized that moment. Financial decisions rarely happen in isolation, yet the information needed to make them is scattered across balances, bills, card statements, and budgeting tools. A balance tells us what we have today. It does not tell us how much is already spoken for.

We built CreditPilot AI to connect those pieces before a decision becomes a financial commitment.

Our idea is simple: before you swipe, know what comes next.

What it does

CreditPilot AI is a financial decision-making application built for web and Android. It connects banking records, purchase comparisons, repayment planning, shared-account approvals, and conversational assistance in one experience.

Its five financial workflows work together:

Home and cashflow forecasting: Combines account balances and upcoming bills into a seven-day forecast, highlighting potential cash shortfalls and when they occur.
SpendAhead card comparisons: Uses a confirmed nearby merchant or manual purchase entry to compare estimated rewards and credit-utilization impact across cards.
Statement Guard and portfolio repayment planning: Calculates one available repayment budget after accounting for upcoming bills and a selected safety buffer, then allocates it across cards.
Joint-account requests and approvals: Gives primary and dependent users distinct roles for proposing and reviewing shared-account payment requests.
Emergency Readiness: Tests an unexpected expense against available funds, committed bills, and a reserve. An optional location-based hurricane budget simulation explores additional planning costs such as food, power, transportation, and lodging.

Two Gemini-powered experiences make these decisions conversational. Ask CreditPilot explains financial context and tradeoffs, while Trip Spending Copilot turns explicitly priced itinerary items into structured purchases for card comparison.

The demonstration uses fictional Capital One Nessie sandbox records and configured demo card terms. Payment execution remains simulated, and the hurricane scenario is a planning exercise rather than an official weather warning.

How we built it

We built the interface with Flutter and Dart, supported by a Python and FastAPI backend and a deterministic financial engine. We developed the web experience, then built and installed an Android APK and tested native authentication on a physical phone.

Our integrations form one connected flow:

Auth0 verifies identity → TigerData resolves account mappings and permissions → Nessie supplies banking records → our financial engine calculates → Gemini helps users understand and explore the result.

Capital One Nessie: the banking foundation

Capital One’s Nessie API powers the banking context throughout CreditPilot. We integrated customer provisioning, account creation, ownership verification, transaction history, upcoming bills, and loan records.

Our core integration covers 18 distinct HTTP method-and-route operations across provisioning, verification, data seeding, and application reads:

Resource group	Endpoint operations	What we implemented
Customers	3	Create customers, list inventory, and verify individual records
Accounts	4	Create accounts, list inventory, retrieve customer accounts, and read individual balances
Merchants	2	Create and retrieve demo merchant records
Transaction history	5	Create/read withdrawals and deposits, and read purchase history when available
Bills	2	Create and retrieve upcoming bill records
Loans	2	Create and retrieve loan records
Total	18	Core provisioning and banking-data integration

Our saved bulk inventory contains 500 customer slots and 512 account references. We enriched three authenticated demo users with:

12 credit cards: four per user, alongside individual checking accounts.
828 verified transactions: 792 withdrawals and 36 deposits over August 18 through October 17, 2026.
18 upcoming bills: six per user.
Six loan records: two per user, including monthly-payment information.
Eight demo merchant records.

The transaction history includes everyday spending, payroll, card-payment activity, and historical bill/EMI payments. Historical activity uses readable withdrawal and deposit records; we do not represent every transaction as a Nessie Purchase object. The intensive histories belong to the three selected users, not every slot in the bulk inventory.

The integration supports decisions across the application. Nessie balances and upcoming bills drive cashflow forecasts. Card balances support purchase comparisons and repayment planning. The same commitments inform emergency assessments, while account-scoped transactions provide a history users can review.

We also retained provider-returned identifiers, verified account ownership, and used a private operation journal to avoid duplicating confirmed records or blindly repeating uncertain writes. Nessie supports the product’s data lifecycle—from preparing realistic scenarios to retrieving the banking context behind each decision.

Auth0: identity across web, Android, and account access

Auth0 powers both the user-facing login and the identity checks behind protected backend requests. Users enter credentials on Auth0’s hosted login page; CreditPilot does not collect or verify their passwords itself.

We configured separate web and Native Android applications while retaining the same existing user identities. Android uses a registered callback scheme to return from hosted authentication to the app. Our backend validates signed access tokens, including their issuer, audience, and expiry, before resolving financial context.

Authentication and account access are separate responsibilities. A valid login establishes identity; it does not automatically expose an arbitrary banking account. CreditPilot retrieves the user’s explicit mapping and checks account ownership before returning financial data.

That supports individual banking views and primary/dependent joint workflows without trusting a client-supplied account owner or treating all authenticated users as interchangeable.

TigerData: persistent mappings and transactional joint state

TigerData provides the PostgreSQL storage connecting authenticated identities to their Nessie records and shared-account permissions. We use it for hashed identity mappings, the imported slot inventory, joint membership, payment-request and approval state, and related application metadata.

This state persists across sessions and backend restarts. Users can sign in again without losing their account mapping or depending on temporary browser state.

For joint workflows, transactional updates and locking protect state transitions and reservation checks across concurrent requests. The backend evaluates the authenticated user’s role before allowing the corresponding action.

Our demo models Parvathi as the primary member, Haswanth as the dependent, and Bindhu as an individual user. Those distinctions are persisted application state—not assumptions based on an email address or whichever account last used the device.

Gemini API: two conversational experiences grounded in account context

We integrated Gemini into both Ask CreditPilot and Trip Spending Copilot, using the model for two different tasks.

Ask CreditPilot receives a limited financial snapshot assembled by the backend from verified account context. Users can discuss spending, bills, purchase goals, and tradeoffs. Bounded recent conversation helps it understand follow-up questions, while optional persistent memory is controlled through user consent and deletion features.

Trip Spending Copilot extracts explicitly priced itinerary items from natural language. A user can describe hotel, dining, and transportation costs in one message; Gemini returns structured purchase inputs that our financial engine can evaluate across cards.

We deliberately kept financial arithmetic outside the language model. The engine calculates rewards, utilization, cashflow, repayment budgets, and emergency gaps. Gemini interprets requests and explains context; it does not invent balances or execute payments.

When information is missing—such as monthly savings capacity—the advisor should ask for it instead of manufacturing a timeline. There is no separately trained custom ML model in this implementation.

Location: connecting the plan to a purchase

With permission, CreditPilot uses device location and a backend Google Places integration to identify nearby merchants. Users confirm the merchant and purchase amount before comparing cards.

Manual entry remains available when location cannot be obtained, and provider keys stay outside the client application.

Challenges we ran into

The hardest challenge was making independently developed features behave like one product.

A card recommendation could look attractive while ignoring a bill due tomorrow. Separate repayment plans could each appear affordable while trying to spend the same available cash. We connected the calculations around a shared financial context and one portfolio repayment budget.

Provider inconsistencies also required careful handling. Some Nessie records could be created but could not be read reliably. We adapted the historical dataset to readable endpoints, verified the resulting records, and tracked operations so retries would not silently duplicate data.

Authentication involved more than displaying a login form. We worked through separate web and Native clients, API access authorization, organization settings, callback handling, and account isolation.

On Android, we configured the SDK, built and installed the APK, connected the phone to the local backend over USB, and diagnosed device-level location permissions. Embedded browsers, regular Chrome, and Android did not behave identically, so we added bounded requests, cancellation, and manual alternatives.

Accomplishments that we’re proud of

We delivered a connected financial-planning application with substantial banking histories, web and Android experiences, role-aware joint-account workflows, and two Gemini-powered conversational tools.

We are especially proud that CreditPilot can recommend restraint.

When available funds are already needed for bills, the repayment planner can recommend monitoring instead of making an early payment. When information is missing, the advisor can ask a question instead of inventing an answer.

We backed the integration with automated financial, API, ownership, and workflow checks, alongside live verification of the three users’ banking records.

The result reflects what we wanted to build from the beginning: a tool that helps users understand their options without pushing every decision toward more spending or a larger payment. Saving a repayment plan does not execute a payment, and we do not promise a particular credit-score outcome.

What we learned

We learned that identity verification, account ownership, persistent state, financial calculations, and AI explanations are distinct responsibilities. Connecting them requires more care than connecting API endpoints.

A successful login does not establish access to every account. A persuasive explanation does not prove the arithmetic is correct. A current balance does not mean the entire amount is available to spend.

We also learned that failure handling belongs in the product. Verifying provider responses, preserving user isolation, preventing duplicate writes, and explaining what went wrong improved the experience and helped our team integrate frontend, backend, and platform work.

What’s next for CreditPilot AI

We want to test CreditPilot with more users and learn which comparisons and explanations help them make decisions. Our next priorities are more complete cashflow inputs, clearer treatment of uncertain expenses, broader device validation, and reliable notification delivery.

We also plan to deploy an HTTPS backend so the Android app can operate independently of a developer’s laptop and USB connection. Longer term, we want to explore consented real-world banking connections with the necessary security, privacy, and operational validation.

Our goal remains the same: help people see how today’s choices affect tomorrow’s commitments—and give them time to act.

Github: https://github.com/parvathinalla/speandahead