Written by Elizabeth Reilly

Valon began as a mortgage servicing company with a mission to modernize an industry that’s still largely running on legacy systems and manual processes. As we’ve grown, our vision has expanded beyond just operating our own servicing business to building a comprehensive platform that any mortgage servicer can use.

Our journey from handling only traditional mortgages to supporting diverse loan products revealed a fundamental engineering challenge: how do we design a system flexible enough to support not just the mortgage loans we’re familiar with, but the full spectrum of loan products in the market?

This post walks through how we rebuilt our architecture to handle any loan type—from conventional mortgages to complex products like Home Equity Lines of Credit (HELOCs)—by breaking loans down into fundamental components that can adapt quickly.

From 1 to N

Until recently, Valon only serviced traditional mortgages, the kind most homeowners are familiar with. These typically work in a straightforward way:

• A homeowner borrows a fixed amount (say $300,000)
• They agree to pay it back over a set period (usually 15 or 30 years)
• Each month, they make the same payment amount, which covers both principal and interest (maybe $1,000 a month)
• The loan has one interest rate (either fixed for the life of the loan or adjusted at predetermined intervals)

Our entire system was built around these assumptions—one loan has one balance and one monthly payment amount. This model worked well for our initial needs, but became a limitation as we expanded to service more diverse loan products.

We recently began servicing our first HELOCs, which operate quite differently. If you’re familiar with credit cards, HELOCs function somewhat similarly but use your home’s equity as collateral. HELOCs can take many different forms, and with the first HELOCs we began servicing, we had to consider that in this product:

• Instead of receiving a lump sum upfront, homeowners get access to a credit line they can draw from multiple times
• Each time a homeowner borrows money (called a ‘draw’), it’s like starting a new mini-loan, with its own interest rate and monthly payment amount
• Homeowners can take additional draws over time (within their approved limit)
• Payment amounts can change monthly based on recent draws and interest rate changes

For example, a homeowner could have a HELOC with a credit limit of $100,000. The homeowner might take an initial $50,000 draw with a $1,500 monthly payment, then later draw another $30,000 with a $1,000 payment. Their total monthly obligation becomes $2,500—the sum of all active draw payments—and they can still draw another $20,000 if they want to. 

Using a HELOC is similar to how you might make multiple purchases on a credit card (up to a limit) and then make a single monthly payment that covers them all: HELOC borrowers make one monthly payment that encompasses all their active draws.

This fundamentally different approach challenged our original system’s design. We could have built a separate system just for HELOCs, but that approach wouldn’t scale as we add more loan types. There can also be significant differences even within the category of HELOCs. For example, some HELOCs begin with an interest-only period, or only allow draws at the beginning of the loan, while others don’t have these attributes. We knew we wanted to expand the types of loans we could service in general, so we decided to step back and rethink what a “loan” fundamentally is, regardless of type.

Modeling a Loan

We realized any loan, regardless of type, could be broken down into: 

• Balance Tracking: A mechanism for tracking outstanding balances that can increase or decrease over time
• Payment Scheduling: A system determining when payments are due and in what amount 
• Payment Allocation: Logic governing how payments are applied to various balances 

Think of these components as the basic questions any homeowner needs to answer: How much do I owe? When do I need to pay? And how are those payments applied?

For traditional mortgages, these components are relatively straightforward:

• Balance Tracking: A single principal balance that only decreases over time
• Payment Scheduling: A fixed monthly payment that rarely changes
• Payment Allocation: Payments that are amortized (divided into a principal and interest component)

For HELOCs, these same components need to handle greater complexity:

• Balance Tracking: Multiple balances for different draws that can both increase and decrease
• Payment Scheduling: Payment amounts that might change monthly as new draws are taken
• Payment Allocation: Sophisticated rules for distributing payments across multiple draws with different interest rates

By reframing loans simply as combinations of these fundamental components, we could create a unified architecture capable of handling both traditional mortgages and HELOCs, while remaining extensible for future loan types.

This modular approach to loan modeling builds on concepts we explored in our previous post about taming the butterfly effect in mortgage models, where we discussed balance tracking and loan accounting in more detail.

Payment Schedules

Let’s look more closely at payment schedules, which determine when and how much a borrower needs to pay. For a traditional mortgage, this is straightforward—the same amount on the same day every month.

A typical, simple mortgage loan originated on 4/1 might have a pay schedule that looks like:

On each due date, the amount due and interest rate are the same. The homeowner pays a consistent amount. 

Now let’s look at an adjustable-rate mortgage (ARM) loan:

This ARM loan had a rate change to 6.5%, increasing the monthly payment to $1,600 starting 8/1.

Conveniently, traditional mortgage loans only have one pay schedule that will be active at any given time, meaning that the arrows on this graph never overlap along x axis. 

There can be additional pieces of information encapsulated in a loan’s pay schedule. For example: 

• Temporary payment deductions or delays (to help a homeowner overcome delinquency)
• Fees, which may be assessed regularly or on a schedule—late fees, for example, are assessed every installment

However, since a traditional mortgage loan always has exactly one active pay schedule, all this information can be stored in a single entity. 

This is not the case for HELOCs, where pay schedules are much more dynamic, based on draws taken. Each new draw is like a mini sub loan, with its own amount due and the possibility of individual rate changes. 

As an example, a HELOC’s pay schedule may look like:

In the above example:

• Initial draw is taken with an amount due of $1,000 starting on the 4/1 installment
• A second draw is taken with an amount due of $500 starting on the 6/1 installment
• A third draw is taken with an amount due of $800 starting on the 8/1 installment

HELOC pay schedules stack, meaning that the amount due at any given date is the sum of the arrows on this graph. This means that on 11/1, the amount due is $800 + $500 + $1,000 = $2,300. 

Even though we could have shoehorned HELOCs into our existing payment model, we wanted to build something that was extendable to other loan variations. Some of these variations include:

• Loans with an interest-only period, where the homeowner initially pays only interest, and then at some point begins paying an amount that goes to both principal and interest
• Adjustable rate HELOCs, where each draw has an adjustable rate, meaning the interest rate for each draw changes over time
• Loans with special delinquency modifications, where payments can be reduced or delayed for a period of time

Rather than reusing a lot of our existing infrastructure for HELOCs, we decided to step back and examine how we could build infra that can better adapt to new loan types, knowing we would encounter many more variants in the future. 

Decomposition

We found that we could break down even complex loan payment schedules into simpler building blocks that worked together. For example, taking the initial adjustable-rate mortgage loan, we can break the pay schedules into:

• Separate schedules for interest accrual and total amounts due
• A separate schedule for late fees (which tend to be fixed for the lifetime of a loan) 

For traditional mortgage loans, there will always be exactly one interest schedule, one principal and interest (P&I) schedule, and one late fee schedule at any time. But decomposing pay schedules in this way becomes especially useful for more complex loan types. 

Take the HELOC from earlier:

Each draw has its own interest schedule and P&I schedule. While this new architecture doesn’t seem too different from the original representation, the real benefits come when we start to look at loan variations. 

Variations

Take the typical mortgage loan from the start, but now assume there is an interest-only period at the beginning:

This can be easily represented by the interest schedule beginning at origination, but the total amount due (P&I) schedule doesn’t begin until 7/1. 

During the interest-only period (before 7/1), the homeowner pays only the accrued interest. Starting 7/1, they must pay the full payment amount, which covers both interest and principal. The payment is applied first to any accrued interest, with the remainder reducing the principal balance. To determine the total amount due at any point, we sum all active payment schedules shown by the overlapping arrows in the diagram.

Now take a more complex HELOC schedule:

This schedule differs from the original in a few ways:

• The interest for a new draw begins accruing on the date the draw is taken, even if the total amount due doesn’t begin until a later installment. This means there is a small interest-only period at the start of each draw. 
• The initial draw was recast by 10/1, meaning the interest rate stays the same but the monthly payment is reduced. Because the interest rate stayed the same, and only the total amount due changed, only a new P&I schedule is created. 

This new graph shows how we can manage a decent amount of complexity, and this is only with respect to HELOCs. New loan types might differ in ways not even represented by the building blocks we currently have, but we can add new building blocks easily and discretely, which helps us innovate quickly. At any point in time, we care only about the vertical set of overlapping arrows.

Breaking down pay schedules in the way described gives us several key advantages:

• Code reuse across loan types: We can share common interest schedule logic between different loan products, even when the specific calculations differ
• Clearer mental model for changes: It’s easier to understand what’s happening when loans change—a rate adjustment creates a new interest schedule, while a recast only modifies payment amounts
• Simpler extension to new products: When we need to support a new loan variant, we can often reuse existing components with minimal changes or simply add small new pieces like a payment deduction schedule

Payment Allocation

Payment allocation (determining how funds are distributed across different balances) is the bread and butter of loan accounting, and thus mortgage servicing. Think of payment allocation as the rulebook that determines exactly where each dollar of a payment goes. Different loan types follow different rulebooks, and the terms of the specific loan will govern. But, typically:

• For traditional mortgages, payments typically follow what’s called the “PITI” model—an acronym for Principal, Interest, Taxes, and Insurance. Each payment is divided up according to a predictable formula.
• For HELOCs, allocation works more like settling a credit card bill. The system first pays off all accumulated interest, then handles any fees, and finally applies the remainder to reducing the principal balance (usually prioritizing balances with the highest interest rates).

Let’s look at how these different approaches work in practice:

For a standard mortgage loan, a payment flows through a decision tree like the one shown above. The system first checks if the loan is current, then determines how to apply the payment based on whether the payment is enough to cover the next installment and if there’s extra money to allocate to additional principal or other categories. This decision tree can be complex. 

HELOCs, however, generally use what’s called a “waterfall” approach:

Each payment cascades down through different categories in strict order—all outstanding interest must be paid first before any money can go toward fees, and all fees must be paid before any money can reduce the principal.

Composable Rules

Rather than writing separate code for each loan type, we wanted to extend the building block model we used for pay schedules. We created small, reusable pieces of allocation logic that could be assembled in different configurations to handle various loan types.

Our payment allocation system includes:

• • Core Allocation Modules: Basic building blocks like “pay interest” or “reduce principal balance” that handle specific payment functions
  • Configurable Hierarchies: Ordered sequences of allocation steps that determine how payments flow through the system
    • For example, one loan type might prioritize interest over fees, while another might prioritize fees over interest
  • Conditional Logic: Special rules that can redirect payment flows based on circumstances
    • For example, if a loan is delinquent, payments might follow a different path to help the homeowner get back on track

• Requested Preferences: Homeowners can request things like applying excess funds to additional principal, but only if strict allocation rules have been met (i.e., all interest was already paid on a HELOC)

This modular approach allows us to represent HELOCs’ complex allocation requirements by simply configuring a different hierarchy of the same base modules we use for mortgage loans, rather than building entirely new allocation logic from scratch.

Take the way installments are allocated and applied:

The way that interest is calculated for mortgage and heloc loans differs:

• Mortgage loans use monthly amortization to calculate interest, which is paid as a portion of installments
• HELOC loans use daily interest, which must be paid to zero before any principal can be applied

But in both cases, the remainder of the payment after interest can be put towards principal at some point in the payment application. So both loan types can ultimately inherit from similar components, and similar logic can be shared. 

This configurable allocation system positions us to support novel loan products without significant architectural changes. As financial institutions innovate with new lending models, we can rapidly implement their custom allocation requirements by reconfiguring existing modules rather than building new systems from scratch.

For engineering teams, this means less duplicated code, clearer boundaries between components, and a more maintainable system overall. For the business, it means greater agility in supporting diverse loan products across multiple servicers, each with their own unique requirements.

Looking Ahead: What’s next for Valon’s architecture?

The journey from supporting only traditional mortgages to building a flexible platform for multiple loan types challenged us to reconsider fundamental assumptions in our architecture. It pushed us to design for extensibility from the ground up while maintaining the reliability and accuracy that financial systems demand.

While our work with HELOCs represents a significant milestone, it’s really just the beginning. The consumer finance landscape is incredibly diverse, with countless loan products. On our roadmap, we’re looking at:

• Supporting more specialized mortgage variants like other HELOC types and reverse mortgages
• Building software for clients that have a diverse portfolio of loan types
• Building deeper integrations with the broader financial ecosystem, including insurance and originations

Each new product brings new challenges, but our modular architecture gives us a strong foundation to build upon. Instead of starting from scratch each time, we can extend our existing components to accommodate new variations, adding specialized modules for unique features while leveraging our core framework. As our understanding evolves, we’ll also iterate on our modular architecture itself to ensure we service more complex loan types, and make enhancements where necessary..

This project exemplifies the kind of engineering challenges we tackle at Valon—problems that require both deep domain expertise and sophisticated software design. We’re building systems that not only serve our immediate business needs but will scale to transform an entire industry.

If you’re excited by the challenge of applying modern software engineering practices to complex domains with real-world impact, we’d love to hear from you. Check out our open positions and join us in building the future of consumer finance.

If you’re interested in becoming part of Valon’s team, and working on problems like these, check out our open career opportunities.