Inspiration

It started with an uncomfortable question: why does getting help with your money almost always mean losing control over it? While researching financial authorization tools for older adults, we kept finding the same two patterns — caregiver controls that are binary (full access or none), and family alerts that only fire after something has already happened, never before.

That's where María came from: 72 years old, recovering from surgery, needs her daughter Laura to help her pay the electricity bill and pick up her medication. María doesn't want to give up deciding. She just needs support to carry out what she's already decided. That distinction — help vs. replacement — became the core of Acordia: turning an informal family favor into an explicit assignment, with clear limits and explainable decisions for both sides.

We got here after deliberately ruling out several other ideas first. We researched real financial pain points before committing to one, specifically to avoid building "just another financial app." Acordia was the one that survived that filter: a specific problem, an underserved population, and a mechanism that wasn't obvious to solve.

What it does

Acordia lets an older adult delegate a specific, time-bound assignment to a trusted family member instead of handing over blanket account access. María describes what she needs in everyday language — "Laura can help me pay the electricity and my medications this month, up to $4,000." The system turns that into a structured assignment: who can help, what they can pay for, how much they can spend, and until when.

From there, every transaction Laura makes on María's behalf is checked against that assignment in real time:

Inside the assignment → approved automatically.
Outside the assignment (wrong category, wrong amount, wrong person) → blocked, with the reason shown.
Technically allowed but unusual (a normal category, but far above the historical pattern) → flagged for review, not silently approved and not silently blocked.

María can always see what was authorized and why any given transaction landed where it did — nothing about her money moves in a black box.

How we built it

Capital One's Nessie sandbox API to simulate accounts, balances, and payments (utility bills, transfers) without touching real money.
A rules engine we built ourselves that validates every transaction against the active assignment — who's executing it, what category it falls under, whether the amount is within the authorized limit, and whether the assignment is still valid in time. This layer is fully deterministic on purpose — no black box here.
Natural-language interpretation with optional Gemini integration to turn María's plain-language request into a structured draft assignment, with a local, rules-based fallback for when that integration isn't available.
Simple, explainable anomaly detection — we compare each transaction against the user's recent history to flag unusual amounts, not a trained model, but direct comparisons anyone can follow and question.
An interface built around the "why," not just the outcome — every approved, blocked, or flagged transaction shows its reason, visible to both María and Laura.

Challenges we ran into

Time. 36 hours forces fast decisions about what actually gets built versus what stays an explicitly stated hypothesis — and resisting the urge to promise more than the prototype really does.
A format incompatibility in mission creation via Gemini that we didn't fully resolve in time. Rather than force a live demo of an unstable feature, we chose to demo with an existing, pre-created mission and be upfront about the pending fix instead of hiding it.
Incomplete permission validation across all routes. We found cases where limit-checking wasn't applied consistently everywhere. We chose not to expose the "edit permissions" or "transfer money" actions in the demo until that's fixed, rather than risk showing a visible security gap live.
Designing for trust without claiming to be the only ones doing it. Caregiver controls and family alerts already exist on the market. Our challenge was articulating an honest differentiation — comprehensible, contextual authorization — without overstating how much of that problem others already solve.
Resisting the pressure to inflate the business case. It was harder than expected to write "this still needs to be validated" on a business-model slide instead of an appealing but made-up number — and to trust that, framed honestly, that's an argument for the project, not against it.

Accomplishments that we're proud of

Landing on a mechanism — an explainable, per-transaction assignment check — that's genuinely non-trivial to build well, instead of settling for a generic budgeting or caregiver-alert app.
Keeping AI and permission-checking strictly separate: the model interprets intent, but a deterministic rules engine decides what's actually allowed. That split was a deliberate, hard-won design choice, not an afterthought.
Being disciplined about honesty under pitch pressure — no invented TAM, no fabricated conversion numbers, and an explicit "what's not ready yet" slide instead of quietly hiding gaps.
Making every decision in the demo explainable in a single sentence a family member could actually understand and act on — not a score, not a black box.
Choosing to pull an unstable feature from the live demo rather than risk showing something broken or insecure, even under time pressure.

What we learned

Explainability isn't a nice-to-have here — it's the product. In a domain where money, trust, and an older adult's dignity are all on the line, a black-box approve/reject isn't good enough. We learned to design every decision to be auditable in one sentence: what was compared, against which limit, and why.
AI and permissions need to live apart. Using a language model to interpret what someone is asking for is useful; using it to also decide whether something gets authorized is dangerous. Separating "interpretation" from "rule validation" turned out to be the single most important architectural decision of the project.
Protecting someone without infantilizing them is genuinely hard. It's easy to design a surveillance system for older adults' finances. It's much harder to design one that keeps them at the center of the decision. We had to double back more than once on whether a feature was "protecting" María or just quietly taking away her authority under a nicer name.
Not inventing numbers is a discipline, not a limitation. It was tempting to fill the pitch with a made-up TAM or an "estimated" conversion rate. We learned to present hypotheses as hypotheses and say plainly what still needs validating — and that, said honestly, tends to land better than an inflated number.

What's next for Acordia

Fix the Gemini mission-creation format incompatibility and bring natural-language assignment creation fully into the live product, not just the demo path.
Close the permission-validation gaps across every route before enabling "edit permissions" and "transfer money" for real.
Add authentication, end-to-end permission checks, and a proper security review — the prototype intentionally skipped these to focus on proving the core mechanism.
Run the proposed 20-family, 4-week pilot with simulated data to test whether people actually understand their permissions, complete their assigned tasks, and find the flags useful — before touching real money.
Validate the licensing hypothesis (banks paying per active family) with real conversations instead of an assumed price point.
Move from simulated Nessie data to a real banking integration once the above is in place, with regulatory review as part of that step, not after it.