Detecting Round Tripping in SME Lending Transaction Analysis
Published on: 2026-04-24 09:20:41
Why transaction analysis matters in SME lending
SME underwriting depends on cash flow. Revenue, inflows, outflows, and timing all matter when you assess repayment capacity. For a long time, only banks had direct access to transaction data. Everyone else worked from bank statements, exported files, or manual uploads.
That model had limits. Bank statements help, but they are static and hard to analyze at scale. They are also awkward for businesses with high transaction volume, multiple accounts, or inconsistent bookkeeping. Open Banking changed that. In the EU, regulation and standardized access made transaction analysis practical for non-banks too.
That shift matters because underwriting can now use real transaction behavior, not just summarized statements. The result is better detection of risk, better segmentation, and better fraud checks. It also means lenders need logic that can inspect transaction patterns, not just totals.
What round tripping is
Round tripping is a suspicious pattern where funds appear to circulate through an account to create the illusion of activity. In lending, the goal is often to inflate revenue or turnover so the applicant qualifies for a higher credit limit or better terms.
The basic pattern is simple. Money comes in, and then money goes out soon after. If you only look at net balance, the account may seem healthy. If you only look at headline revenue, it may seem active. But the flow of funds tells a different story.
This behavior can be deliberate fraud, or it can sit in a gray zone of misleading financial presentation. Either way, it distorts underwriting decisions.
Why basic checks are not enough
The first generation of round-tripping checks looked for a single in-and-out pair in a short time window. That works when the pattern is simple. It fails when the applicant knows the check exists.
Suspicious patterns are often more varied:
- One incoming transaction followed by multiple outgoing transactions.
- Several smaller inflows combined to fund one outgoing transfer.
- Amounts that do not match exactly, but fall within a tolerance band.
- Repeated inflow and outflow patterns over time.
- Transactions that do not appear immediately adjacent, but still form a linked sequence within a defined window.
This is the core problem. Detection has to be flexible enough to identify combinations, but controlled enough to avoid false positives. A strict one-to-one match misses real cases. A loose match creates noise.
How to detect round tripping properly
Effective detection starts with a time frame. You need to examine transactions within a defined interval, then look for combinations of inflows and outflows that could plausibly be linked.
The second control is tolerance. Real transaction patterns are rarely exact. Fees, partial spending, split transfers, and operational delays can create differences between incoming and outgoing amounts. A practical detection rule needs percentage tolerance, not exact equality.
That gives you a workable structure:
- Identify incoming transactions.
- Identify outgoing transactions.
- Evaluate them inside a configured time window.
- Generate possible inflow and outflow combinations, up to configured limits.
- Compare the total incoming and outgoing amounts.
- Flag combinations where the totals fall within the configured percentage tolerance.
- Return the matched transactions, matched volume, and number of detected pairs.
The useful result is not a verdict. It is a risk signal. That signal should feed underwriting, manual review, or a broader fraud workflow.
Example detection logic
Suppose an applicant receives several payments over 2 days. Soon after, the account sends out several payments. The outgoing total is close to the incoming total, but not exact. One payment is 99.4% matched, another is split into two transfers, and a third would only be caught if the tolerance threshold is configured broadly enough.
A simple rule would miss that. A better rule checks candidate pairs and combinations within a time window and allows for a percentage tolerance. That is the kind of decision logic you need in SME lending, where financial behavior is often noisy.
Why structured transaction analysis helps
Transaction analysis often starts with a volume problem. You need to read many rows, normalize them, and inspect patterns across time. That is where structured transaction logic helps.
Decisimo’s data flow rule type supports transaction analysis by preparing transaction data for rule-based evaluation. Within that flow, the Fraud Pairs function can evaluate combinations of incoming and outgoing transactions using time frame and tolerance rules.
For round tripping, Fraud Pairs is designed to detect suspicious combinations of IN and OUT transactions. It looks for transaction sets where money is moved in and then moved out within a configured window, with amounts that match or nearly match.
This approach is useful because the fraud logic remains explicit. You can configure the time window, tolerance, and maximum number of transactions included in the matching process. That keeps the rule easier to inspect, tune, and audit.
What the Fraud Pairs function does
The Fraud Pairs function looks for transaction pairings and combinations that fit a suspicious pattern. It is not limited to one incoming transfer matched against one outgoing transfer. It can evaluate multiple candidate combinations within the configured window.
That matters because real-world behavior is rarely neat. Businesses may split payments, combine receipts, or move money through several steps before it exits the account. The function has to work with that reality.
In practical terms, Fraud Pairs helps you:
- Detect linked inflow and outflow patterns.
- Handle one-to-many and many-to-one combinations.
- Allow percentage-based tolerance between values.
- Use time proximity as part of the signal.
- Control matching complexity with maximum IN and OUT transaction limits.
- Surface suspicious cases for review or automated action.
The function can also be configured to use working days only, so weekends are ignored when calculating the matching window.
To avoid duplicate matches, transactions that are successfully matched are marked as used. This means the same transaction is not repeatedly reused across multiple fraud sets.
How this improves SME underwriting
Underwriting should answer one question: can this business repay safely? Transaction analysis helps answer that question with evidence. Round-tripping detection improves it further because it identifies overstated activity before the lender prices or approves the deal.
That gives lenders three benefits:
- Better accuracy. You reduce the chance of treating recycled money as genuine revenue.
- Better control. You can explain why a case was flagged, because the rule is explicit.
- Better speed. You can automate the first pass and reserve manual review for edge cases.
This is where deterministic decision logic matters. The Fraud Pairs check follows defined transaction patterns within a known frame, with known tolerances, and with a clear audit trail.
Common implementation mistakes
Teams usually fail in the same places.
First, they make the time window too narrow. Suspicious movement often spans more than a single day. If the window is too small, the pattern disappears.
Second, they require exact amount matching. That creates avoidable misses. Real transactions rarely match to the cent when money is split or consolidated.
Third, they ignore many-to-one and one-to-many cases. That is now a major gap, because simple pair checks are easier to avoid.
Fourth, they treat a flagged pattern as proof of fraud. It is not proof. It is a signal that should affect underwriting, pricing, or review.
Fifth, they set transaction grouping limits without testing performance. Larger combinations may improve detection, but they also increase processing cost.
Sixth, they build the logic in a place where it is hard to inspect. If a lender cannot trace why a case was flagged, the process is weak.
How to operationalize the detection
A practical deployment usually follows this sequence:
- Ingest transaction data through Open Banking or another approved source.
- Normalize the data into a structured transaction format.
- Apply the Fraud Pairs function with a defined time window and tolerance.
- Set maximum IN and OUT transaction group sizes.
- Use working-days calculation if the business context requires it.
- Route the result into underwriting, manual review, or fraud scoring.
The output should include the matched IN transactions, matched OUT transactions, matched volume, and number of detected fraud pairs. This gives analysts enough context to understand the signal and review the underlying transactions.
Why explainability matters
Round-tripping checks can affect credit availability, pricing, and onboarding outcomes. If a lender blocks an application, the reason must be defensible. If a lender raises manual review, the reason should be visible to the analyst.
That is why the detection logic should be auditable by design. You need the raw inputs, the matching logic, the time window, the tolerance threshold, the matched transactions, and the final outcome. If any of those are hidden, the process becomes harder to trust.
Explainability is not a reporting layer added later. It is part of the rule itself.
Built-in performance safeguards
Combination matching can become expensive when transaction volume is high. Fraud Pairs includes built-in safeguards to protect the system from performance and memory overload.
The function limits the number of transactions evaluated within a single time window. It also limits the number of IN combinations tested. These limits prevent large transaction windows from creating uncontrolled combinatorial searches.
That matters in SME lending because some applicants may have high transaction volumes. The rule should be tuned carefully, using small windows and sensible transaction limits, before being used in production.
What this means for non-banks
Open Banking made transaction analysis available to lenders that do not hold customer accounts. That is a real change. It means non-banks can inspect payment behavior directly, rather than infer it from statements alone.
But access alone is not enough. You still need decision logic that can catch abnormal behavior without overblocking normal business activity. Round tripping is one example. There are others, but this one is common enough to deserve explicit treatment.
If you lend to SMEs, transaction analysis is now part of underwriting. The question is not whether to use it. The question is whether your logic can detect the patterns that matter.
Conclusion
Round tripping is a practical fraud problem in SME lending. It becomes harder to spot when the pattern moves beyond a simple one-in, one-out check. You need time-based matching, percentage tolerance, and the ability to evaluate combinations of transactions.
Decisimo’s data flow rule type supports that kind of analysis. Within the flow, the Fraud Pairs function can inspect linked IN and OUT transaction patterns and surface suspicious activity before a credit decision is made. It gives lenders a controlled way to analyze transaction data, explain the outcome, and keep underwriting rules auditable.