How Loan Replay™ works
The Loan Management System (LMS) is a lender’s system of record as well as their financial ledger, storing all of the financial events that occur in relation to each loan. The happy path for any loan is for each payment to be made on its due date. In this scenario, the ledger simply progresses with its expected entries as time moves on, and lenders do not typically encounter any major issues.
However, the real world is often quite different from this happy path, and there are a number of edge cases that can cause significant disruptions for lenders. Particularly challenging are scenarios that affect loans retroactively.
Consider the case where an ACH payment fails 45 days after it was made. (ACH payments can be disputed for up to 60 days.) For an interest-bearing loan, it's not sufficient to “remove” the amount paid from the loan’s ledger (for example, by debiting the loan by the same amount that was previously credited). Instead, the loan needs to account for the additional interest that would have accrued if the original payment had not been made.
Another salient example is a retroactive change to a loan’s interest rate, which also requires a recalculation of interest accrual—and a reapplication of interest/principal splits for payments. We explored this example in our post about how Peach handles interest-rate adjustments in the context of the Servicemembers Civil Relief Act (SCRA).
There are a few possible ways to support retroactive changes in an LMS. The simplest approach is to fiddle with the ledger on an ad-hoc basis to arrive at the correct outcome. This method is manual and error-prone, and any bugs or issues—especially for more complex lending constructs such as lines of credit—render the ledger useless. A slightly better approach would be to create a new branch of the ledger each time a retroactive change is made. This branch would record an up-to-date view of all events from that point on. This method retains the previous ledger history, but makes it significantly harder to accurately calculate the loan balance, as it requires traversing the various branches a ledger might have.
At Peach, we’ve approached the problem differently than the two methods described above. We call our approach Loan Replay™, and it’s a capability native to our Adaptive Core™ loan management system. In effect, we’ve woven into our LMS the ability to automatically perform recalculations when retroactive changes are made, and to preserve the full loan history before and after those changes. Loan Replay makes it easy for agents to backdate payments, fail past transactions, retroactively change interest rates and more through the same intuitive Agent Portal they ordinarily use (the same functionality is also available via API).
The way we approached Loan Replay also enables us to support lines of credit with multiple sub-lines (amortized or revolving credit), which carry significantly more complexity for retroactive changes. The first two methods described above would likely make it almost impossible to correctly adjust past events.
At the core of Loan Replay is an event sourcing system that emits events as they happen. Such events include “loan.interestaccrued” and “payment.applied” as well as more complicated actions such as “loan.rate.created.”
=================================
For a loan with a weekly payment frequency with auto payment:
Day 0: loan.created
loan.rate.created
loan.activated
payment.instrument.created (bank account)
Day 1: loan.interestaccrued
Day 2: loan.interestaccrued
Day 3: loan.interestaccrued
Day 4: loan.interestaccrued
Day 5: loan.interestaccrued
Day 6: loan.interestaccrued
Day 7: loan.movebalances.nonduetodue
transaction
payment.applied (payment via bank account)
payment.pending
Day 8: loan.interestaccrued
Day 9: loan.interestaccrued
Day 10: loan.interestaccrued
Day 11: payment.suceeded (ach payment cleared)
.
.
.
=================================
Some events are simply there to mark an occurrence, while other events will add entries to the ledger. Each event of the latter kind knows how to read the state of the ledger and of the loan, and knows what ledger entries it needs to add in order to record its changes. In the case of a past failed payment, Peach will simply mark the transaction object as failed and it will “go back in time,” invalidating all ledger entries from the time the original transaction was applied to the ledger until the date the transaction failed. Our system will then replay all events in that same time frame.
When Loan Replay processes the “payment.failed” event for the failed transaction, it will simply skip it and will not write it to the ledger, because the event is now marked as “Failed,” and from an accounting perspective it's as if the payment never existed in the first place.
In a similar way, when a loan’s interest rate must be retroactively changed, a new rate with a past date is added to the system and a replay is initiated from the effective date of that new interest rate. The replay will invalidate all ledger entries from its starting point until today, and will begin replaying all events during that time frame. When it reaches an “Accrue Interest” event, it will use the new rate and will accrue the interest based on the ledger balance for that day and the interest rate defined. When it comes time to reapply previously successful payments, the interest/principal splits will reflect the newly accrued interest with the new rate.
Peach’s immutable ledger and events preserve a clear audit trail and ensure that lenders never lose any of their data or loan histories. Our ledger is queryable before and after replays—showing exactly what was changed and how.
A few thoughts on the design of our platform
Because of the many dependencies that affect ledger immutability, the functionality of Loan Replay can’t just be bolted onto an existing loan management system. That’s why we built it as a core part of our platform, weaving it into the fabric of our LMS. This approach is emblematic of the way Peach builds, and of our company value, Think long-term.
Many other loan management systems in the market started with installment loans, and when the time came they added support for lines of credit. This required rewriting their code and making certain compromises for expediency and to minimize impact to the installment loans already in flight. The result is platforms with certain inflexibilities that make Loan Replay-like functionality very challenging.
For this reason, we designed Peach from day one to be agnostic to asset class, so that our underlying technology, data model and core software construct can utilize the same code to support both installment loans and lines of credit. This enables all our clients to use the functionality of Loan Replay as part of their day-to-day operations—failing past payments, changing interest rates retroactively, waiving past fees, canceling purchases on draws and more. Loan Replay is also integral for lenders who leverage our Supported Portfolio Migration™ capability.
At Peach, we’re always taking the path of configurability, ensuring that all our clients are leveraging the same code base and benefiting from the full breadth of our functionality as they find new and better ways to improve lives through innovative lending products.