The Credit Card Compass

Inspiration

One of our teammates recently opened her first credit card, and she described the whole process as feeling like a guessing game: which bank do you actually trust with your money? Review sites felt gamed, star ratings felt meaningless, and there was no real way to know how a company would treat her the day something actually went wrong.

We were given the CFPB Consumer Complaint Database, a free, public record of hundreds of thousands of real complaints filed against financial companies, along with exactly how each one was resolved. That felt like the missing piece. Credit cards are nearly universal in American life (82% of U.S. adults held one in 2025, according to the Federal Reserve), but access to good information about them isn't: the Fed also found that 97% of households earning $100,000 or more have a credit card, compared to just 46% of households earning under $25,000 (Forbes Advisor, 2025). The people with the least room to absorb a bad banking relationship are often the ones with the least information to avoid one.

So we set out to turn that guessing game into a compass reading, a clear, evidence-based direction instead of a coin flip.

That idea felt like a natural fit for this year's challenge theme, AI for Social Good. We didn't want to build a flashy model for its own sake; we wanted to take a public dataset that already existed and put it directly into the hands of the people it was meant to protect, using AI as the translation layer between a dense government database and an everyday decision.

What we learned

The biggest lesson, hands down: real-world data is messy. We expected to spend most of our time on modeling; we actually spent most of our time on cleaning. Company names weren't standardized (the same bank appears under several legal-entity variations). A meaningful share of complaints were still marked "In progress," meaning they had no real resolution yet and had to be excluded rather than treated as a finished outcome. Issue categories weren't consistent either: the CFPB's own taxonomy has been revised over the dataset's 15-year span, and some categories (like a catch-all "Other" bucket) were too vague to responsibly map into a consumer-facing category, so we made the call to exclude them rather than force a fit.

We also learned how easily a percentage can mislead if you don't check your sample size first. Some company-and-issue combinations had thousands of complaints behind them; others had a handful. We set a minimum complaint threshold before trusting any relief-rate percentage, which meant losing some categories entirely, but gaining confidence that every number we did show was real signal, not noise.

How we built it

Data pipeline (Python/pandas, in Google Colab): loaded the CFPB dataset, filtered to credit card complaints for four major banks, removed unresolved complaints, and computed relief rates (the share of complaints closed with monetary or non-monetary relief) for each bank and issue type.
Concern mapping: grouped the CFPB's specific issue categories into six broader, plain-language categories a first-time cardholder could actually understand (Billing/Disputes, Customer Service, Account Management, and so on), then recomputed relief rates at that level.
A transparent weighting model: rather than asking users to pick categories directly, we designed six short quiz questions, one dedicated question per concern, so every answer maps clearly to exactly one category. Answers translate into priority weights, which are shown to the user before anything is ranked, with the option to adjust any of them.
A ranking engine: banks are ranked by a weighted average relief rate across the user's selected priorities.
An interactive front end (HTML/CSS/vanilla JavaScript): a three-step flow (quiz → confirm priorities → ranked results), with a color-coded, clickable visualization showing exactly how much each concern contributed to each bank's score.
A companion data dashboard (R/Shiny): to reinforce our commitment to transparency, one teammate built an interactive R Shiny dashboard that lets anyone explore the underlying relief-rate data directly, by bank, by category, and across years, including a live version of the same weighted-ranking logic used on the main site.
Mini user studies: we tested the tool with real people at several points during development, deliberately including someone who had never opened a credit card before. That testing is what surfaced our biggest design problems early, like quiz questions using jargon ("carrying a balance," "end to end") that didn't mean anything to a first-time applicant, and a category name ("Application/Approval") that users assumed meant something totally different from what it actually measured. We revised the quiz wording, added plain-language explanations under every question and category, and added inline definitions to the results page based directly on that feedback.
Deployment: hosted as a live site via GitHub Pages, with the full analysis notebook and dataset included in the repository for transparency, and the dashboard hosted separately via shinyapps.io.

Challenges we faced

The hardest problem wasn't the data analysis, it was translating that analysis into something a real person with zero finance background could use without feeling lost. Our first version of the quiz used category names straight from our own analysis (like "Application/ Approval"), and early testers had no idea what that meant or why it existed as its own category. We had to rewrite every question and category with plain-language descriptions, and in some cases rethink the categories themselves, so that someone opening their first credit card could understand exactly what each priority meant and why the tool was asking about it. This is where our mini user studies mattered most: rather than guessing what would confuse someone, we watched real users get stuck in real time and iterated the design around what actually tripped them up, not what we assumed would.

A related challenge was making sure a user's quiz answers mapped cleanly and honestly onto our underlying data categories. It was easy to build a quiz that felt intuitive to us as the people who'd already done the analysis; it was much harder to build one that mapped one-to-one onto real data categories without any hidden assumptions, so that every ranking we showed could be traced back to an explicit, inspectable reason.

We also worked hard to keep our promise of transparency real rather than just a talking point: the tool shows its inferred priorities before ranking anything, lets users override them, and displays the actual complaint counts behind every percentage, so nothing is a black box. Building that layer of interpretability took as much design work as the underlying ranking logic itself.

A note on tools

As a team of beginner coders working within a 24-hour time constraint, we used AI tools (Claude and ChatGPT) to help write and debug code for the website, analysis notebook, and dashboard. The project's core ideas, data analysis approach, and design decisions are our own; AI assistance helped us translate those ideas into working code more efficiently than we could have otherwise.