Why payments experience is the thing that is hard to fake
Most engineers who can wire up an LLM have never run money movement, and most payments engineers have never shipped production AI. The value in fintech AI work sits exactly at that intersection, and it is hard to fake because payments punishes handwaving. Ledgers have to balance. Idempotency has to be real or you double-charge people. Reconciliation, disputes, chargebacks, KYC/KYB, and fraud rules are not features you bolt on later; they are the system.
I spent roughly three years as Director of Engineering at a neobank, where the platform moved $720M in payments at 100% uptime. I led 17 engineers across 5 products. On the customer-facing side I owned all commits on the Snap! Spend React app and wrote core payments code across the platform — not a demo, a live consumer money app people trusted with their paychecks.
The payments stack I have actually shipped
These are concrete systems I have built and operated in production, not a survey of things I have read about:
| Stripe Connect (multi-tenant) | Marketplace and platform payments where funds route across many connected accounts, with the fee, payout, and liability model that implies. |
|---|---|
| Plaid ACH | Bank-linked ACH money movement: account linking, balance and ownership checks, and the debit/credit flows that sit on top. |
| Apple Pay & Google Pay | Mobile wallet acceptance wired into the customer-facing app. |
| Fraud rules | Rule-based decisioning to catch bad transactions before they settle, tuned against real loss data rather than a vendor default. |
| KYC / KYB | Know-Your-Customer and Know-Your-Business identity and onboarding checks, the gate every regulated money product has to pass. |
| Multi-tenant platform | Separately, a payments and field-ops platform on Stripe, Temporal, and Postgres in Rust/Node on GCP, where Temporal workflows make multi-step money and ops flows durable and retry-safe. |
What "AI for fintech" means here: signed and auditable
The reason most fintech teams are cautious about AI is not that the models are dumb. It is that a compliance, risk, or legal team cannot defend a decision they cannot reconstruct. A standard LLM gives you an answer and no defensible record of why. In a regulated money business, that is a non-starter.
So the AI I build for fintech is signed, anchored, and independently auditable by construction. Every decision that matters is captured with its full context and committed to a tamper-evident record:
- Inputs — the request, the prompt, and the model and version that ran.
- Context — the exact retrieved documents and any tool calls or data the model saw.
- Output — the answer or action the system produced.
- A cryptographic signature over all of it, using ML-DSA (a NIST-standardized post-quantum scheme), anchored so any later edit is detectable. A provisional patent has been filed on this approach.
The point is not to make records impossible to touch; it is to make any touch obvious. An examiner or auditor recomputes the hash and verifies the signature independently, without having to trust the operator. That is what turns "the AI decided X" from an assertion into evidence. If you want the full argument, see signed, auditable AI vs. standard LLM guardrails and how to make LLM outputs auditable and trustworthy.
Prove the answer is right, not just recorded
Signing proves what happened; it does not prove the answer was good. A perfectly signed wrong decision is still wrong, and in payments a wrong decision moves money. So the fintech AI I build pairs signed auditability with an evaluation harness that backtests output against historical ground truth. Before a prompt, model, or retrieval change ships, it is replayed against a corpus of past cases with known-correct answers and scored. Quality becomes a number you can defend, not a vibe — which is exactly the standard a fintech risk committee expects.
The rest of the toolkit
Beyond payments, the production AI I ship end to end includes model gateways that route tool-using agents, RAG for grounding answers in your own documents, and real-time voice agents — there is a live one you can actually talk to. I have also built Nectar, a programming language in Rust that compiles to WebAssembly with a public compiler and 2,500+ tests, which is a reasonable proxy for how much correctness-by-construction I am willing to build into a system.
On the frontend side, the fintech relevance is direct: I have roughly a decade of React and TypeScript, owned all commits on the Snap! Spend consumer app, built a WebRTC platform for the Emmys in React in five weeks, and built a React dashboard on a Rails EHR (Medaxion) — so regulated, high-stakes UI is not new ground. If you specifically need AI features in an existing React product, see senior React engineer to build AI features.
Building something where AI touches money?
For fintech AI or payments engineering — Stripe, ACH, fraud, KYC/KYB, and AI whose every decision is signed and independently auditable — get in touch.
Email blake@hibiscus.buzz