How It Works
From raw settlement feeds to a closed exception queue — in minutes, not days
Txnworks ingests every data source, normalizes to a canonical transaction model, runs four-way matching with corridor-specific rules, and surfaces only the exceptions that need human attention. Five steps. No spreadsheets.
Connect your data sources
Connect PSP settlement files (API push or SFTP pull), acquirer transaction reports, and bank statement feeds. Supports CSV, ISO 20022 XML, and proprietary PSP formats. Median setup time: 2 hours per data source.
Connectors authenticate via OAuth 2.0 or API key. SFTP endpoints support key-pair and password auth. All file transfers are TLS 1.3 encrypted in transit.
Normalize to a common transaction model
All incoming data is normalized to Txnworks' canonical transaction model — currency, amount, merchant reference, settlement date, and acquirer ID unified across sources.
FX rates are sourced from ECB and local central bank feeds, timestamped at both authorization and settlement separately. This gives you a precise variance baseline per transaction, not a blended daily rate.
Format transformations are handled server-side. Your team sees a unified view regardless of how many different file formats your PSPs send.
Four-way match
The matching engine runs in real-time on each incoming settlement file. Four legs of every transaction are checked:
- Auth × Capture — configurable ±0.5%–2% tolerance; flags if capture amount deviates beyond threshold
- Capture × Settlement — partial capture detection; multi-currency settlement netting
- Settlement × Bank Credit — amount match within tolerance + timing window match per corridor
Corridor-specific rules: Pix real-time vs batch end-of-day GPN handled natively. Known local rail behaviors (weekend settlement delays, holiday batch windows) are pre-configured per corridor.
Prioritized exception queue
Unmatched and mismatched transactions surface in an exception queue ranked by financial impact ($ amount at risk). Each exception is pre-classified:
- FX variance — applied rate differs from ECB/central bank rate
- Settlement timing gap — bank credit outside expected window
- Missing bank credit — settlement file confirms but bank has no matching credit
- Duplicate capture — same authorization captured twice
- Acquirer fee mismatch — fees differ from contracted rate
AcqPay Int'l · 2h ago
VoltSettle · 3h ago
IndonesiaSettle · 5h ago
Resolve and close
Exceptions are resolved in-app with a full audit trail. Three resolution paths:
- Dispute filing — one-click dispute generation with the PSP or acquirer
- Manual match override — flag as matched with a documented reason code
- Write-off with classification — GL-coded write-off for reporting purposes
Every resolution action is timestamped, attributed to a user, and logged in the append-only audit trail. Resolved exceptions feed back into pattern analysis: if a corridor consistently shows a known FX offset or timing gap, Txnworks adjusts the tolerance rule for that corridor going forward.
Resolved items export to your GL or ERP with corridor attribution and exception type classification — in CSV or ISO 20022 format on demand or on a scheduled cadence.
See it run on your own corridor data
We run through all five steps using a sample of your actual settlement files — so you see exactly where your exceptions are before you commit. 30 minutes, no preparation required on your end.