About Txnworks
Built in Chicago by people who've run payment ops where reconciliation is hardest
Founded in 2024, Txnworks exists because no general-purpose accounting tool handles the multi-rail, multi-currency complexity of operating in Brazil, Nigeria, and Southeast Asia — and payment ops teams were spending 40+ hours a week finding that out.
Why we built this
Ryan Matsuda spent six years building payment infrastructure at a fintech focused on LatAm and Southeast Asian corridors. The pattern he saw repeatedly: merchants growing their cross-border volume were also growing their reconciliation problem. Three PSPs in four countries meant three different settlement file formats, three different FX rate conventions, and three different interpretations of what "T+1 settlement" actually meant.
The standard fix was ops staff manually reconciling CSV exports from every PSP into a shared spreadsheet — a process that ran 40+ hours a week per analyst, produced outputs 48–72 hours after settlement, and still missed systematic FX variance because no one had time to do rate-by-rate comparison at transaction level. By the time exceptions surfaced, PSP dispute windows had closed and FX hedging was moot.
The tools available were either general-purpose accounting software (built for invoice reconciliation, not settlement files) or internally-built tools that took 18+ months to deliver and broke whenever a PSP changed their export format. Txnworks was founded in Chicago in 2024 to be the specialized reconciliation layer — built specifically for multi-rail, multi-currency, emerging-market complexity — that those merchants needed but couldn't build themselves.
The team
A small team with deep roots in payment operations, financial data engineering, and cross-border infrastructure.
Nine years building settlement and reconciliation infrastructure at fintechs focused on LatAm and Southeast Asia. Spent six of those years watching ops teams manually reconcile Pix, SPEI, and GPN settlement files before writing the first version of Txnworks' matching engine.
Distributed systems engineer with deep experience in high-throughput financial data pipelines. Previously built real-time settlement infrastructure processing 800K+ daily transactions at an acquiring bank, and led data engineering at a payments API platform covering Africa and South Asia.
Seven years in payment operations and treasury at African e-commerce platforms, managing multi-corridor reconciliation workflows across Nigeria, Ghana, and Kenya. Brings direct operational knowledge of NIP, M-Pesa, and GhIPSS settlement quirks — the kind that doesn't appear in any documentation.
Integration architect with six years building PSP and acquirer connectors for enterprise payment platforms in Brazil, Mexico, and the Philippines. Specialist in ISO 20022 transformation, SFTP settlement file normalization, and reverse-engineering proprietary PSP export formats that have no published schema.
How we operate
Specificity over abstraction
Cross-border reconciliation has dozens of rail-specific edge cases. We solve them precisely — Pix T+0 handling is not the same as GPN batch end-of-day, and our matching engine treats them differently. Txnworks is not a general payments platform.
Exceptions resolved the same day they occur
The financial cost of an exception compounds when it sits unaddressed. Txnworks surfaces every mismatch with enough context — corridor, PSP, amount at risk, root-cause classification — to close it within the same settlement cycle.
Minimal integration surface
Payment ops teams already run complex stacks. Txnworks connects via read-only credentials and standard file formats — no changes to existing PSP configuration, no new settlement routing, no infrastructure modifications required.