Fiducia — Open Source Digital Banking Platform

The first open-source, multi-tenant digital banking platform for credit unions and community banks. Built in a week with AI. MIT licensed. Fork it, deploy it, skip the seven-figure vendor contract.

Comment

Inspiration

I've spent 3+ years building white-label digital banking platforms for credit unions, community banks, and financial institutions in a B2B2C model. I know what goes into them — the architecture decisions, the integration complexity, the implementation timelines that stretch across quarters, and the seven-figure enterprise contracts that come with all of it.When the industry started debating whether AI would eat SaaS, I didn't want another think piece. I wanted to run the experiment in a domain I knew well enough to evaluate the output honestly.The question I actually wanted to answer: if AI is going to eat SaaS, where does it start and where does it stop?I picked digital banking on purpose. Heavily regulated, clearly defined core primitives, an established ecosystem of third-party services, and a long history of high-cost implementation. If AI was going to hit a ceiling, this seemed like the right place to find it.

What it does

Fiducia is a multi-tenant digital banking platform for credit unions and community banks — the first of its kind released under MIT license.It ships the full surface area of what a commercial white-label platform delivers: Consumer banking — accounts, loans, cards, bill pay, remote deposit, open banking consent management (CFPB Section 1033) Business banking — AI-powered accounts payable, smart cash sweeps, just-in-time approval workflows, liquidity forecasting, treasury vaults across four providers FI administration — tenant configuration, branding, feature toggles, SSO (SAML 2.0 + OIDC), A/B testing, CMS Compliance scaffolding — mapped to SOC 2 and FFIEC controls, PII classification, encrypted storage, full audit trail Core banking simulator — mocks CU*Answers, Symitar, and Fineract with chaos engineering built in 23 adapter domains — swap any vendor without touching business logic 180+ API endpoints — fully typed gateway client Three deployment modes — shared SaaS, dedicated instance, or headless/embedded Commercial platforms charging enterprise licensing fees — Q2 Holdings ($795M revenue in 2025), Alkami ($443M projected 2025) — are the incumbents this replaces as a starting point.

How we built it

Honestly: I was watching TV for a good chunk of it. I fired off short questions between episodes — "find other bill pay providers," "what cores should I integrate with internationally," "how do I make onboarding easier for a new developer?" — the same half-formed inputs I'd throw at a team. No PRDs. No design specs. What I established upfront was a domain-driven architecture: bounded contexts, clear separation between core banking primitives and surrounding service layers. That became the directional frame. Then I pointed AI at vendor documentation and said go. I ran parallel agents across workstreams simultaneously — consumer banking, business banking, compliance scaffolding, public website, CMS, A/B testing. Early on I had AI generate the README and architecture documentation as infrastructure, not afterthought — feeding those documents back into subsequent sessions to maintain context as the project scaled. The whole thing took a week.

Challenges we ran into

Information asymmetry, not capability. AI flew through every integration with public documentation. It stalled completely on proprietary schemas — closed core banking APIs, undocumented KYC/AML vendor formats. That boundary turned out to be the most important finding. Context window budget management. Large feature builds consumed the context window, leaving test coverage thin at the end of sessions. Learned to checkpoint explicitly, scope sessions to either build or test — not both for large features. Keeping AI on track. Without active redirection, agents chased interesting problems rather than necessary ones. The commit history reflects this honestly — more commits than a focused build would have produced. Persistent memory. AI has no memory between sessions. The README and architecture MDs had to be built early and maintained deliberately as the project's memory layer. Without them, context drifted beyond recovery.

Accomplishments that we're proud of

Shipped capabilities that publicly traded incumbents don't have — AI invoice processing, just-in-time approval workflows, autonomous execution governance, open-source core banking simulator with chaos engineering Full CFPB Section 1033 compliance scaffolding — consumer consent management, granular data scopes, access logging, one-click revocation ISO 20022 interoperability — pain.001, pacs.008, camt.053 — FedNow and SWIFT compatible Platform abstraction layer — same business logic runs on Supabase, AWS Lambda, Cloudflare Workers, or bare Node MIT licensed with zero vendor lock-in — fork it tonight, deploy it tomorrow Proved the thesis: the integration layer that justified multi-million dollar implementation contracts is reproducible by one person with domain knowledge and access to public API documentation

What we learned

The moat was never the software. It was always information asymmetry — the closed ecosystem of schemas, API contracts, and integration specifications that weren't published anywhere. The moment a vendor publishes clean documentation, that portion of the moat is gone. You need to bring the SDLC knowledge. AI executes. It doesn't know when to stop building and run the documentation loop, when testing coverage is insufficient, when to refactor, or when the plan it generated is confidently wrong. That judgment — built over years — is what made this possible. Without it the same experiment produces an expensive mess. Formalized agent personas would have made this more efficient. A dedicated architecture reviewer, SDLC guardian, security auditor, documentation writer — each with defined scope and persistent context — would have reduced drift and produced cleaner output. That's the mature version of this workflow. Worth doing properly at scale. The implementation partner who survives this moves up the stack. Not integration delivery — strategic integration selection. Not hosting — architectural governance. Value-add work, or commodity pricing. There is no third option.

What's next for Fiducia — Open Source Digital Banking Platform

Immediate — already in progress: Adding adapter support for Algolia (search), Storyblok (CMS), and Neo4j (fraud graph analysis) — following the existing adapter pattern, consuming public API documentation, demonstrating exactly what the project argues: public schemas collapse the integration barrier. Near term:

ACH batch origination and positive pay — the remaining gaps vs. commercial incumbents in business banking Plaid and MX adapters for data aggregation — both have public documentation, both are straightforward additions Flutter mobile app hardening — functional today, needs production polish Community contributions — the MIT license is an invitation; the adapter pattern makes it easy for anyone to add a vendor integration without touching core business logic

Bigger picture: Fiducia's value isn't the features — it's the starting point. Every credit union or community bank that forks this skips 12-18 months of architecture work and $500K-$1M in initial platform costs. The goal is to build a contributor community around that shared foundation. The real north star: Get to a point where a credit union CTO can fork Fiducia on a Friday, have a working demo environment by Monday, and make a legitimate build-vs-buy decision with actual information instead of a sales pitch. That's the gap this fills. Nothing else does it today.

Built With

Share this project:

Updates

Submission history