# Payment Hub: We Killed the Multi-Loan Payment Spreadsheet

> When a client has five loans and sends one wire, traditional loan management systems force your accounting team to split, allocate, and reconcile every payment by hand — every single time. Payment Hub turns that mess into a single transaction with smart distribution rules built directly into timveroOS. One entry point, automatic allocation across loans, manual override when you need it, full rollback if anything goes sideways. It’s a new building block on the timveroOS Building Platform, and it solves a problem that’s been quietly burning out accounting and collections teams across banks, fintechs, and credit unions for years.

**Author:** Dmitriy Wolkenstein  
**Published:** 2026-05-21  
**Reading time:** 9 min  
**Category:** Product Updates  
**Tags:** Banks, Fintechs, Credit Union

![Payment Hub](https://ha30txtppzucbkza.public.blob.vercel-storage.com/payment-hub-hero-1280x700.png)

---

## Why We Built This

Here’s a scenario we kept hearing from clients running multi-product portfolios on timveroOS. A small-business client has a working-capital line, a piece of equipment financing, and a short installment loan with the same institution. At the end of the month, they don’t pay each one separately on the due date — they send one wire for whatever cash they have, whenever they have it, and expect the lender to “figure it out.”

That “figure it out” is where things break. The accounting team opens a spreadsheet, pulls obligations, decides which loan eats the principal first, which one takes interest, what goes toward fees, and what stays unallocated. Multiply that by hundreds of mixed payments a day and you’re not running a lending operation — you’re running a reconciliation department with a lending product attached.

The frustrating part: this isn’t a niche problem. It happens everywhere a client holds more than one credit obligation with the same lender. We saw it at Tier 3–4 banks with cross-sold portfolios. We saw it at fintechs processing salary deductions and standing orders. We saw it at credit unions where a single member might hold a car loan, a personal loan, and a credit line at once. Different ICPs, identical pain.

## The Real Problems This Solves

We broke the problem down by who actually feels it day-to-day. Three audiences, three different versions of the same headache.

### For accounting teams: stop fragmenting one payment into five entries

In a loan-level model, every consolidated payment becomes N transactions — one per loan touched. That means N audit trails, N reconciliation lines against the bank statement, and N opportunities for a typo to silently break the books. Payment Hub captures the **single** transaction the bank actually received, then distributes from there. The audit trail mirrors reality, not the workaround.

### For collections: the prioritization rule is no longer in someone’s head

When a partial payment comes in, which loan gets covered first? The overdue one? The largest? The one closest to default? In most LMS setups, that decision lives in policy documents and gets applied inconsistently by whoever is on shift. Payment Hub turns that policy into **executable distribution rules** — loan prioritization, tranche ordering, and obligation hierarchy (principal → interest → fees → penalties) — that run the same way every time.

### For analytics: payment behavior stops looking like noise

If one client wire turns into five loan-level payments, your “on-time payment rate” and “average days delinquent” metrics get distorted by allocation choices, not by actual client behavior. Keeping the transaction whole, and tracking distributions as a separate event, gives you a clean view of how clients actually pay — and a clean view of how you decided to apply it.

## What We’ve Actually Built

## ![Payment Hub in timveroOS: one client transaction distributing across multiple loans via Smart Distribution rules](https://ha30txtppzucbkza.public.blob.vercel-storage.com/payment-hub-client-level-transaction-diagram.webp)

Payment Hub is exposed as a client-level layer that sits between incoming funds and your existing servicing logic. Five capabilities, each available through the admin panel and through the SDK for clients who want to extend or override the defaults.

**Single entry point.** Each transaction captures the total received amount, the client, the currency, the document reference, the date, and the payment purpose. That’s it. One record, one source of truth, one line in the audit log.

**Smart Distribution.** Automatic allocation across the client’s active loans based on rules configured on the Building Platform per project — loan prioritization, tranche ordering inside credit lines, and obligation hierarchy. Distribution is deterministic and explainable: every cent has a documented reason for landing where it did.

**Manual Distribution.** When the client says “this one is for the equipment loan, the rest is for the line,” you create payments on specific loans directly from the transaction. Smart Distribution stays off; you stay in control. Each manually created payment still flows through the same obligation hierarchy inside that loan.

**Unallocated amount management.** Partial allocations are a first-class state, not an error. If a client overpays the targeted loans, the leftover stays on the transaction as an explicit unallocated balance, ready for a future allocation or a refund decision.

**Payment Rollback.** Any individual payment can be canceled, returning funds to the transaction’s unallocated pool. Useful for distribution errors, for redistribution after a loan condition changes, and for partial reallocations during dispute handling.

## How Smart Distribution Actually Decides

This is the part most people want to understand before they trust the automation, so let me walk through it.

When a transaction with Smart Distribution arrives, the engine evaluates the client’s portfolio against three layers of rules:

1. **Loan prioritization** — which of the client’s active loans receives funds first. Configured per project; common patterns include “most overdue first,” “highest delinquency severity first,” or “by product type with credit lines ahead of installment loans.”
2. **Tranche ordering** — inside credit lines or facilities that carry multiple tranches, the priority sequence for which tranche gets serviced first.
3. **Obligation hierarchy** — inside each selected loan or tranche, the order in which principal, interest, fees, and penalties consume the available funds.

The whole thing is configurable on the Building Platform, not buried in vendor code. If your jurisdiction requires fees-before-interest in some products and interest-before-fees in others, you encode that as a building block, not as a special request to your LMS vendor’s roadmap.

![Smart Distribution three-layer rule engine: loan prioritization, tranche ordering, and obligation hierarchy in timveroOS Payment Hub](https://ha30txtppzucbkza.public.blob.vercel-storage.com/payment-hub-smart-distribution-rule-layers.webp)

This is one of the points where the Building Platform model shows its value: distribution logic is a [loan servicing software](https://timvero.com/loan-servicing-software) capability that most lenders don’t get to shape. With timveroOS, your engineers extend the rules through the SDK directly. No support ticket, no six-month roadmap negotiation.

## The Transaction Lifecycle

Four states, mapped to what’s actually happening with the money.

| **Status** | **What it means** |
| --- | --- |
| **Unallocated** | The transaction is linked to a client, but no funds have been distributed to loans yet. |
| **Partly Allocated** | Some funds have been distributed; a remainder is still available on the transaction. |
| **Allocated** | The transaction is fully distributed across one or more loans. |
| **Void** | The transaction has been canceled. Only reachable from the Unallocated state. |

![Payment Hub transaction lifecycle states: Unallocated, Partly Allocated, Allocated, Void](https://ha30txtppzucbkza.public.blob.vercel-storage.com/payment-hub-transaction-lifecycle-states.webp)

A transaction can move back from Allocated to Partly Allocated when a payment is rolled back, and from Partly Allocated back to Unallocated when all payments on it are canceled. Every state change is logged with operator, timestamp, and reason.

## Where It Lives in timveroOS

Payment Hub isn’t a bolt-on integration. It’s a native building block on the timveroOS Building Platform — entities, state machines, and services that sit inside the same architecture as origination, scoring, and servicing. That matters for two reasons.

First, lenders don’t have to build a payment-allocation engine from scratch. The behavior that takes 6–12 months of in-house engineering to get right — idempotent rollbacks, obligation ordering, partial-allocation edge cases — ships as a configurable building block on day one.

Second, when a client needs distribution logic that isn’t in the defaults — a specialty-finance lender with covenant-driven allocation, a fintech with custom waterfall logic for BNPL split-pay, a bank with jurisdiction-specific obligation ordering — they don’t file a feature request and wait. They extend the block through the SDK. This is what we mean when we talk about the Building Platform sitting between SaaS configuration ceilings and the 18–24 month custom-build path. You get the working system from day one **and** the architectural control to shape it.

## What This Means For You

Payment Hub will land hardest for three groups of lenders running on timveroOS:

- **Multi-product banks and credit unions** with cross-sold portfolios — members and customers who hold a credit line, an installment loan, and a card with the same institution, and pay them in one go. See more on [lending software for banks](https://timvero.com/bank-lending-software) and [lending software for credit unions](https://timvero.com/lending-software-for-credit-union).
- **Fintechs running batch consolidated payments** — salary deductions, standing orders, employer-side payroll deductions, B2B installment plans where one merchant settles across many obligations. See more on [lending software for fintechs](https://timvero.com/fintech-lending-software).
- **Specialty lenders with directed payments** — factoring, leasing, asset-based lending, private credit, where the client specifies which obligation a payment is for, and the system must respect that without losing the audit trail.

If you’re already on timveroOS, Payment Hub is being rolled out as part of the platform; your implementation team will walk you through configuring distribution rules for your project. If you’re evaluating timveroOS and this kind of operational friction is on your list of “things our current LMS makes worse,” this is one of the building blocks worth talking through on the call.

[Request a demo →](https://timvero.com/request-a-demo)

## Frequently Asked Questions

### What is Payment Hub in timveroOS?

Payment Hub is a client-level transaction layer in timveroOS that captures consolidated payments as a single transaction and distributes the funds across the client’s active loans. It supports automatic distribution via configurable rules, manual override per loan, partial allocation, and full rollback — all on the timveroOS Building Platform.

### How is Payment Hub different from recording payments on each loan separately?

Traditional loan-level payment recording forces one consolidated client wire to become multiple loan entries — fragmenting the audit trail and distorting payment behavior analytics. Payment Hub keeps the transaction whole at the client level, then distributes it through a separate, logged event. You get one source of truth and a clean view of both intent and allocation.

### Who configures the Smart Distribution rules?

Distribution rules — loan prioritization, tranche ordering, and obligation hierarchy — are configured on the Building Platform during implementation. Defaults cover common patterns; client engineers can extend or override the rules through the SDK for jurisdiction-specific or product-specific cases without waiting for a vendor roadmap update.

### Can a Payment Hub transaction be reversed if something goes wrong?

Yes. Individual payments inside a transaction can be canceled, returning funds to the transaction’s unallocated pool for redistribution. An entire transaction can be voided, but only while it’s still in the Unallocated state. Every state change is logged with operator, timestamp, and reason for full audit support.

### Does Payment Hub work for both consumer and commercial lending?

Payment Hub is product-agnostic — it operates on transactions, clients, and loans as generic timveroOS entities. It is used by consumer lenders processing salary deductions, by commercial lenders handling cross-sold portfolios, and by specialty lenders managing directed payments on facilities like factoring lines or construction draws.

### Where does Payment Hub fit relative to the rest of timveroOS?

Payment Hub is a native building block on the timveroOS Building Platform, alongside origination, scoring, servicing, and the loan accounting engine. It is accessible through the admin panel for operators and through the SDK for engineering teams who want to extend distribution logic for their specific lending products.

---
Source: https://timvero.com/blog/payment-hub-we-killed-the-multi-loan-payment-spreadsheet