We built Txnworks because rules engines were costing us real money.
Not an AI platform pitch. A practitioner's response to a specific, expensive problem.
Origin story
Before starting Txnworks, I spent three years as a risk operations lead at a mid-size payment processor in Chicago. We ran a rules engine that had been accumulating rules since 2018. By the time I joined, it had 340 active rules — and it was generating 2,400 false positives for every confirmed fraud case we caught.
The cost wasn't just ops labor. Every false positive was a real customer who got their transaction declined for no legitimate reason. We were losing merchants who got frustrated with the friction. And we were still missing synthetic identities, because rules match patterns — and synthetic identity fraud deliberately assembles patterns that no single rule covers.
"We had a rule for every attack we'd already seen. We had nothing for the attacks that looked like normal behavior until they didn't."
Txnworks started as a proof of concept: replace rule-based velocity and geo checks with a behavioral signal model that trains on outcome data. The first version ran in a staging environment alongside our production rules engine for four months. It caught 40% more fraud at a false positive rate under 0.3%.
We started Txnworks in 2024 to make that proof of concept available to other payment fraud and risk ops teams — without requiring a six-month enterprise vendor evaluation.
— Ryan Matsuda, CEO & Co-Founder
Three people, one focus.
Ryan Matsuda
CEO & Co-Founder
Former risk ops lead at a Chicago-based payment processor. Spent three years running a rules engine before building a better scoring model. Founded Txnworks in 2024.
Aisha Oduya
ML Engineer, Fraud Signals
Builds and tunes the 140+ behavioral signal set. Focuses on signal feature engineering, false positive calibration, and the feedback loop that keeps signal weights updated on outcome data.
Marcus Chen
Backend Engineer, API Infrastructure
Owns the scoring API, worker architecture, and latency budget. Responsible for keeping P50 at 44ms and P99 under 80ms under production load.
How we work.
Explain the score.
Every API response includes contributing_signals[] with weights. Your ops team needs to understand why a transaction was flagged — not just that it was. A score without explanation is a black box, and black boxes erode trust with merchants and internal teams alike.
Minimize false friction.
False positives are not a minor inconvenience — they are real customers declined for no reason. Our threshold defaults are calibrated conservatively because we would rather you tune toward more friction than have us ship a product that declines good transactions out of the box.
Feedback > rules.
A static model gets stale. We built the feedback loop as a first-class feature because the only way a scoring system improves is if it learns from confirmed outcomes. POST /v1/feedback is not an afterthought — it is the core of how the model stays calibrated to your specific transaction mix over time. Txnworks is not the right fit if you need a rules engine you can edit in a UI — we score against behavioral signals, not configurable rule trees.
Based in Chicago.
Reach us directly — we respond to all inquiries within one business day.