Lending Terms Glossary for Fintech Teams
A lending term is a word fintech teams use to describe how credit is created, structured, serviced, tracked, or closed. This glossary explains lending terms for fintech product, engineering, servicing, operations, and compliance teams. It's not borrower guidance on choosing a loan, comparing rates, or seeking credit terms.
Origination sets up the loan, and underwriting checks borrower eligibility and possible credit terms before Peach begins its role in the lifecycle. Peach starts at post-origination, once disbursement, KYC, and underwriting are finished, and handles servicing tasks like account management, payments, borrower outreach, delinquency management, and collections.
Each entry opens with a clear definition, then adds the operational or system context a fintech team may need. Use the alphabetical index to jump to a term or browse by category.
Alphabetical index of lending terms
This index links to all 25 terms in the glossary.
API | Asset class | Buy now, pay later (BNPL) | Case management | Charge-off | Collections | Compliance | Compliance Guard™ | Delinquency | Draw | Immutable ledger | Installment loan | Line of credit (LOC) | Loan management system (LMS) | Loan portfolio | Loan Replay™ | Loan servicing | Loan tape | Origination | Payment processing | Post-origination | Revolving credit | Sub-ledger | Underwriting | Webhook
Loan lifecycle terms
Loan lifecycle terms split the work that creates credit from the work that follows funding. Peach begins at post-origination. It does not perform origination, underwriting, or credit decisioning.
Origination
Origination is the process that creates a loan through application, credit review, approval, and funding. It turns a request for credit into a funded loan. Peach does not perform origination. Teams that use Peach should keep origination and post-origination servicing systems distinct. Their system plans should show that split.
Underwriting
Underwriting is the evaluation of whether a borrower qualifies for credit and what terms may be offered. It covers credit assessment and decisioning before post-origination servicing starts. Peach does not perform underwriting. It does not make credit decisions. Those decisions must be complete before a loan enters Peach's product scope.
Post-origination
Post-origination is the period after disbursement, know your customer checks, and underwriting are complete. This is Peach's product-scope boundary. It covers the ongoing work needed once a loan exists.
Loan servicing
Loan servicing is the ongoing work of managing a loan after it is created. It can include account upkeep and payment handling. It can also cover borrower messages, delinquency work, and collections. Servicing is the work itself. A loan management system is software that supports that work.
Loan management system (LMS)
A loan management system (LMS) is software used to manage loans through the post-origination period. In Peach's scope, an LMS is distinct from origination and underwriting systems. It supports post-origination servicing work. Teams evaluating whether to build or buy loan management software may weigh an in-house build against a vendor.
Lending products and credit structures
Credit-structure terms define how funds become available and how credit can be used. Installment loans, revolving credit, lines of credit, draws, and BNPL each work in a different way. A lending system must record each structure as designed.
Asset class
An asset class is a category of lending product. Peach supports installment, revolving, buy now, pay later, and line-of-credit structures. An asset class groups products with shared core traits. Products in the same class can still have different setups. Peach does not support federal student loans.
Installment loan
An installment loan is a loan with a defined amount and repayment period. Its structure sets the amount and the term for repayment. Payment patterns can vary. Teams should keep that range in their product models, schedules, reports, and servicing rules. Equal payments are not part of the base definition.
Revolving credit
Revolving credit is credit that can be used, repaid, and used again up to an available limit. Credit cards and lines of credit are common forms. Available credit changes as a borrower uses and repays funds. The system must track the credit limit. It must also track the amount available under the product's rules.
Line of credit (LOC)
A line of credit (LOC) is a revolving facility that allows repeated borrowing through draws up to a limit. The line sets the available amount. Each draw records one use of that amount. In Peach's model, draws can have their own structures. The line and its draws stay as separate parts of the lending record.
Draw
A draw is a borrowing sub-unit within a line of credit. In Peach's data model, each draw has its own identifier. It can carry its own interest or promotional rate. A draw stays distinct from the purchase or transaction that may have led to it.
Buy now, pay later (BNPL)
Buy now, pay later (BNPL) is a credit structure that divides a purchase obligation into installments. The term covers a group of lending products. Schedules and product setups can vary within that group. Product and engineering teams should use the BNPL structure approved for their program. They should use it when defining repayment schedules, servicing behavior, and borrower communications.
Servicing and lending operations terms
Servicing and operations terms cover work done after a loan starts. This includes accounts, payment status, exceptions, recovery work, portfolio views, and data delivery.
Loan portfolio
A loan portfolio is a lender's loans viewed together for operating, reporting, and performance purposes. The set of loans depends on the question being asked. It is not limited to active loans in every case. Teams may define views for servicing, finance, risk, reporting, or other approved needs.
Delinquency
Delinquency is a state in which a borrower is behind on a scheduled payment. The term names a payment status. It does not set one number of days for all loans. It does not automatically mean default. A lender's contracts, policies, and rules set how its program groups and handles delinquency.
Charge-off
Charge-off is a loan status showing that the lender has charged off the account. The account stays in the servicing record. In Peach's data model, a charged-off loan can be assigned to a collection agency. Peach remains the system of record.
Collections
Collections is the work done to recover overdue balances. A lender may handle collections internally or involve a collection agency. Involving an agency does not necessarily mean the debt was sold.
Case management
Case management is a structured process for borrower events, disputes, restrictions, and exceptions. A case can have a status, assigned tasks, structured fields, and review rules. It can also set restrictions on interactions. Servicing and compliance teams use the case record for review and approval. They can also use it for follow-up or controlled communication.
Payment processing
Payment processing is the movement and status handling of borrower payments through bank, card, or external processing arrangements. Peach supports turnkey, bring-your-own-bank, and external-processing patterns. These are three ways to set up processing. A lender's approved setup links payment instructions, movement, status, and servicing records.
Loan tape
A loan tape is a loan-data output that can be set up for reporting or delivery to an investor or capital-markets partner. Its fields and format depend on the approved data needs of the receiving party. So does its delivery schedule.
Lending systems, data, and integration terms
Systems and integration terms explain where lending records are stored. They also explain how software shares data. These terms help engineering and operations teams mark the bounds of a lending core, linked systems, and user tools.
Immutable ledger
An immutable ledger is a ledger design that keeps original entries when a correction is applied. It marks the original entry as invalid. It does not overwrite that entry. In Peach's system, the original stays in the record with its new validity status. The corrected entry is then added.
Sub-ledger
In Peach's deployment model, Adaptive Core can operate alongside an existing core as a sub-ledger, or as the primary lending core. Integration documents should state which role it has.
API
An application programming interface (API) is a programmatic interface through which software systems exchange requests and responses. Peach documents a RESTful, resource-oriented API. It also provides portals for users. An API supports system-to-system interaction. A portal gives people a visual interface. A fintech team may use both in the same setup.
Webhook
A webhook is an event notification one software system sends to another when a subscribed event occurs. The linked system receives the notice without asking for the same status again and again. Use current Peach API docs for supported subscriptions and implementation details.
Compliance and Peach capability terms
Compliance terms split a lender's legal and operating duties from software controls. Those controls can support approved servicing work. Peach tools in this section have narrow jobs set by the source.
Compliance
Compliance is the controls and operating work used to follow applicable lending laws, regulations, and program rules. The lender and its qualified legal and compliance teams hold these duties. Software can support controls and their use. It does not replace legal judgment. It cannot make a lender compliant on its own. This glossary is a technical reference. It does not give legal advice.
Compliance Guard™
Compliance Guard™ is the umbrella for two Peach products with distinct jobs. Compliance Guard Monitor opens cases from monitored borrower events. Compliance Guard Rules checks outbound communications and can block them. Both support controls within Peach's loan servicing platform. Neither gives a broad legal-compliance guarantee. Lenders remain responsible for their legal and compliance duties.
Loan Replay™
Loan Replay™ is Peach's retroactive recalculation feature. It applies a servicing change at a past effective date. It then replays the interim period forward and keeps ledger history. Loan Replay™ recalculates loan state from the corrected input. It does not reconcile or match records across separate systems.
Commonly confused lending concepts
These distinctions stop nearby terms from being used as substitutes. Each row gives the narrow difference supported by the source.
ConceptsDifferenceOrigination, underwriting, and servicingOrigination creates the loan. Underwriting evaluates borrower qualification and potential credit terms. Servicing manages the loan after it is created. Peach handles post-origination servicing. It does not handle origination or underwriting.Installment and revolving creditAn installment loan has a defined amount and repayment period. Revolving credit can be used, repaid, and used again up to an available limit.Loan portfolio and loan tapeA loan portfolio is a lender's loans viewed together for operating, reporting, and performance. A loan tape is a data output set up for reporting or delivery.Recalculation and reconciliationRecalculation applies corrected inputs and updates loan state. Reconciliation compares records across systems. Loan Replay™ is a recalculation feature.
About this glossary
Travis Ross is the author. This glossary was last updated July 10, 2026.
Frequently asked questions
These answers use the fintech operating meaning of lending terms. Borrower-facing definitions may use the same words in a different way.
What is a lending term?
A lending term is a word used for how credit is created, structured, serviced, tracked, or closed. Here, it means words used by fintech product, engineering, servicing, operations, and compliance teams.
What are common loan terms?
Common loan terms for fintech teams include origination, underwriting, post-origination, loan servicing, installment loan, revolving credit, line of credit, delinquency, charge-off, collections, payment processing, and loan management system. Their exact meaning depends on the product and how the team uses it.
lender’s priority list. But that doesn’t mean compliance is straightforward, even for lenders with the most earnest intentions. Often, legacy infrastructure is the culprit, making it difficult for lenders to take the actions clearly outlined in the law. Even regulations that haven’t changed for some time—like the—still present significant challenges for many lenders.
The SCRA grants active-duty service members the ability to request certain protections during the period of their deployment, enabling them to devote their energy to serving the country. These protections include a reduction in interest rate to a maximum of six percent on any pre-service loans. While the SCRA in its current version has been law since 2003, the number of recent enforcement actions indicates just how difficult it is for many lenders to comply with the SCRA’s interest rate protections.
Blunt tools in the absence of a scalpel
For example, in October of 2022 the Department of Justice (DOJ) announced that the financial leasing arm of GM agreed to pay over $3.5 million to resolve allegations in relation to
Peach’s approach to SCRA
At Peach, we brought real-life lending experience to the design of our platform. So from day one, we recognized the importance of being able to make retroactive changes to loans. (There are numerous applications beyond SCRA, including our Supported Portfolio Migration.) In the case of SCRA, Peach has long enabled lenders to retroactively change interest rates and waive past fees—as separate, manual actions.
Peach’s approach to SCRA
This was functional, but the ideal way to implement SCRA is to make these changes simultaneously. We now support this capability by leveraging the power of Peach's Loan Replay™ engine, which can make changes to the ledger at any time, and then recalculate a loan’s history in light of those changes. The new combined functionality is as user-friendly for your agents as processing a payment.
Peach’s approach to SCRA
Specifically, the new SCRA feature allows your agents to perform the following adjustments simultaneously on a loan of an active-duty service member:
- Lower interest rates to 6% (and lower the recurring payment during the active-duty period to account for the interest rate reduction)
- Waive fees, if necessary
- Enact these changes retroactively, if necessary, and replay the loan history with the rate and fee adjustments
- Preview the intended changes
“We launched our first product on Peach in six weeks. Eighteen months later.”
John Smith, CMO
Our SCRA functionality is available via API as well as through our white-label agent tool. The white-label agent interface can be seen here:
Peach’s approach to SCRA
Our SCRA functionality is available via API as well as through our white-label agent tool. The white-label agent interface can be seen here:
For those working directly with the API, this can be as simple as sending the following request body to the SCRA endpoint:
You’ll receive a response with either the actual post-SCRA adjusted payment plan or a preview of it. Below is a comparison of a payment plan prior to the SCRA adjustment, and the expected payments after the SCRA adjustment. The SCRA period is in effect for the first two months, and thus you will see the interest rates lowered to 6% in the response body (and the recurring amount due lowered by the amount of the interest rate reduction for the two relevant months). The origination fee has also been canceled.
The breadth of loan data needing to be adjusted means that rewriting loan histories requires the right design and abstractions, and having a built-in layer of abstraction to handle retroactive changes is the only feasible approach. Because of our team’s combined experience in the real world of lending, we know that the need to edit past loan events is inevitable. So we’ve designed a system that makes these changes as painless and automated as possible.
