Bank data is the messiest input in consumer software. Feeds arrive late, restate themselves, change a merchant's spelling between the pending charge and the settled one, and occasionally hand you the same transaction twice with different identifiers. The person using our app does not care about any of that; they care that their balance is right.
You would own the layer that absorbs the mess: Plaid ingestion, webhooks and the sync backstop, deduplication, the mapping from a bank's idea of an account to ours, and the graceful handling of the day an institution changes its mind.
What you would do
- Own the Plaid integration end to end — link, sync, webhooks, re-consent and the failure modes of each.
- Design idempotent pipelines: running the same sync twice must not create a second transaction.
- Turn institution-specific weirdness into a single normalised shape the engine can post from.
- Keep our third-party spend honest — every billable call should be one we needed.
What we look for
- 4+ years of backend engineering, ideally with async Python.
- You have integrated an API that lies to you sometimes, and built the reconciliation to catch it.
- Comfortable with queues, retries, backoff and the difference between at-least-once and exactly-once.
Nice to have, never required
- Plaid, Finicity, MX, Teller or an open-banking aggregator in production.
- You have been on call for a data pipeline and improved the alert that woke you.
If you are on the fence
Every list above describes the person we imagine, not a checklist we score. People who meet most of it and want the rest have done extremely well here. If the role reads like the job you want next, that is enough reason to write to us — tell us which part you would have to grow into and we will be straight with you about whether it works.
Send whatever shows your work best — a CV, a repository, a portfolio, or a few paragraphs. A hiring manager reads every one, and you will hear back within two business days.
Apply by emailcareers@lumaledger.app