Loan origination system (LOS)

Origination is the start of a loan's life, from the application to the moment the money is paid out. A loan origination system runs that stretch as a sequence of steps: it takes the application, collects and checks the applicant's data, runs identity and fraud checks, assesses creditworthiness, makes or supports the decision, prepares the offer and the pre-contractual information, gets the agreement signed and triggers the payout. Then the loan moves to the loan management system, which keeps the loan account, the repayment schedule, interest, arrears and closure.

The line between the two is a design choice. Many platforms sell both functions as one product, and the names overlap. A useful way to separate them: the LOS is a decision pipeline that ends with a yes or no and an offer, and the loan management system is a ledger that follows the money until the last repayment. The customer app or web portal is a third layer that talks to both; it is neither the LOS nor the ledger.

Most steps of the pipeline depend on outside services: identity verification for KYC, a bank account check through open banking or a verification transfer, credit bureau data, in Poland the PESEL restriction register, and fraud checks. Each of them can fail, time out or return a result that needs a person to look at it, so the application is best modeled as a state machine with explicit statuses rather than a straight line of screens.

In an LOS, every decision has to be explainable later. Requirements for the system:

• Every decision has a record. Store the application, the outside data with the time it was fetched, the model or scorecard version with its result, the policy version and the result of each rule, and the final decision. Then any past decision can be replayed on the same inputs.
• Rules are versioned, not only code. Models, rules, data sources and product configuration change on their own schedule, and each decision should point to the versions it used.
• People can review decisions in the system. When a person reviews or changes a decision, the system records who, when and why. Under CCD2 a consumer can request human intervention after an automated creditworthiness assessment, so the review needs its own path in the product.
• Fraud checks are a separate module. They answer a different question than credit scoring, and the AI Act treats them differently: AI systems used to evaluate creditworthiness are high-risk, while those used to detect financial fraud are excluded from that point.
• Cheap checks run before paid ones. Internal rules and simple eligibility checks can stop an application before a paid bureau query, and a repeat application from the same person can reuse a recent bureau result for as long as the credit policy allows.
• New and returning customers differ. A repeat loan can reuse verified data but still needs its own checks, such as the PESEL restriction check before every new agreement in Poland.
• One pricing engine feeds every channel. The calculator, the pre-contractual information form and the agreement should take amounts and APR from the same engine.

Under Article 18 of the new Consumer Credit Directive, CCD2, the creditor must assess creditworthiness before concluding the agreement, document its procedures and the information used, and, when the assessment relies on automated processing of personal data, let the consumer obtain human intervention: an explanation, a chance to give their view and a review of the decision.

In Poland the Consumer Credit Act already requires an assessment before the agreement (Article 9). A loan institution may grant credit only after a positive assessment, based on data from trusted providers such as credit bureaus and business information bureaus. If that data is not enough, it takes a statement of income and fixed household expenses with supporting documents, and it always takes one when the total amount of credit exceeds twice the minimum wage (Article 9a). Before every agreement and every amendment that increases the debt, the lender checks the PESEL restriction register (Article 9b). Pre-contractual information goes to the consumer on a durable medium, on the standard information form (Articles 13 and 14). Under the AI Act, Regulation (EU) 2024/1689, AI systems intended to evaluate the creditworthiness of natural persons or establish their credit score are high-risk, except those used to detect financial fraud (Annex III, point 5(b)).

We have built the customer side of origination, not the decision engines. In the app we have built for AvaFin Poland since January 2026, AvaFin's central system decides the order of the loan application steps and the app displays them. The calculator takes prices from the same pricing engine as the central system, so the amount in the app is the amount in the agreement. The customer can verify a bank account by logging in to their bank or with a verification transfer, during registration and in the loan application, and the app checks the device with a fraud prevention service on the first loan application. While the decision is pending, the app shows a screen saying the application is being analyzed.

In Aasa24, the lending app we have built and developed for Aasa Polska since May 2023, more than 40 application and loan states are translated into plain messages. The PESEL check is a step of the application with its own status, and the card application has its own KYC status.