Blog
Working notes and analysis from the Txnworks team. Written for people who already know what a PSP is and want to understand why their settlement data doesn't add up — and what to do about it.
A transaction-level breakdown of how FX conversion slippage, unreconciled settlement timing gaps, and aging exceptions compound into 3–5% gross revenue loss for merchants running multi-corridor payment stacks.
Pix settles in seconds. NIP/NIBSS operates on T+1 batch windows. GPN can vary by acquirer. M-Pesa has its own file format. This piece explains why settlement lag differs so dramatically across corridors, and what each gap means for your reconciliation workflow.
The rate your acquirer applies at authorization is rarely the rate that appears on the settlement file. This piece maps the three most common FX mismatch patterns — and how to detect each one at transaction level rather than discovering them in month-end variance.
What your reconciliation stack actually needs when you're running five PSPs across eight corridors: the data model decisions, feed normalization choices, and exception workflow design that determine whether your ops team is ahead of problems or always behind them.
Card network dispute rails (Visa Reason Codes, Mastercard DMs) don't apply to NIP, Pix, or GPN chargebacks. This piece covers how dispute timelines, evidence formats, and escalation paths differ across the local rails where cross-border merchants lose money on unrecovered disputes.
A walkthrough of the canonical transaction model Txnworks uses to normalize settlement files from heterogeneous PSPs — covering field mapping decisions, FX rate attribution (auth-time vs settle-time), corridor-aware settlement window logic, and how to handle partial captures without double-counting.