03 · self-directed build · feb 2026
FinConnect
An open banking data aggregation platform, built as a working simulation to demonstrate how I think about systems: architecture, data normalization, and above all what happens when things fail. This is not client work. It exists so you can break it and watch it recover.
the problem
Every institution speaks a different language.
Fintech products depend on user financial data, but every institution exposes different APIs, auth methods, schemas, rate limits, and failure behaviors. Aggregators like Plaid abstract some of it, and the rest is a platform design problem: normalizing inconsistent data, managing token and consent lifecycles, and handling the failure modes that hit at scale.
the simulation
Pick a failure. Watch the recovery.
FinConnectopen banking simulation
system online
Select a scenario
try a failure scenario to see the error handling work
Client app
web · mobile
API gateway
auth · rate limit
Plaid service
link · sync
Data store
postgres · redis
Webhook processor
plaid events
Notification service
email · push
Event stream
0 events
Waiting for events...
Raw → normalized
Data appears as the simulation runs...
simulation powered by mock plaid api schemas
500+ institutions supported
design decisions
Three calls that shaped it.
Error taxonomy first
Most production edge-case bugs come from unhandled failure modes. Designing the taxonomy before the features prevents cascading issues later.
Normalize, never pass through
Each institution returns a different schema. Without a normalization layer, every downstream feature handles N variations instead of one clean model.
Webhooks over polling
Polling hundreds of institutions wastes resources and delays updates. Webhooks give real-time sync, with polling kept as the graceful fallback.
learnings
The hardest part of system design is not the happy path, it is failure handling at scale. A clear error taxonomy up front prevents most edge-case issues before they exist. And data normalization across institutions is a product challenge, not just a technical one: API platforms require thinking in systems, not features.