Upgrading the Lending Stack

Consumer credit needs more than just better underwriting: it needs a more integrated lending stack built on onchain infrastructure designed for real-world finance.

Published on
April 14, 2026
Summary

Consumer lending is a big part of how individuals and households navigate the modern economy. People rely on credit to finance major life events (buying a new home or car, starting a college degree, opening a small business), cover emergencies, smooth cash flow, and stay economically mobile and liquid even when expenses temporarily outweigh income. Credit is also critical to society: it expands purchasing power by allowing consumers to acquire things they could not otherwise afford upfront, and contributes significantly to economic growth, social mobility, and long-run improvements in living standards. One might even say it is credit, not love, that makes the world go round.

The numbers make the point more clearly:

  • In the United States, total consumer credit outstanding, excluding mortgages, was around $5.1 trillion in 2025. In Q4 2025 alone, total US credit card debt reached $1.28 trillion, auto loan debt roughly $1.67 trillion, student loan debt roughly $1.66 trillion, and other non-housing consumer debt (including retail cards and consumer finance loans) about $564 billion.

  • In Canada, the second-biggest economy in North America after the US, consumer debt crossed $2.6 trillion as of 2025. Mortgage balances accounted for approximately $1.8 trillion, with the remaining non-mortgage debt spread across credit cards, auto loans, lines of credit, and personal loans.

  • In Europe, consumer credit in the eurozone reached roughly €807 billion in late 2025, and total household lending across the EU stood at approximately €7.7 trillion as of 2023 (about 45% of Europe’s GDP at the time). Germany, the eurozone's largest economy, held roughly €234 billion in outstanding consumer credit in 2025. In the UK, the annual growth rate of consumer credit reached 8.3% as of early 2026, with total outstanding balances estimated at approaching £250 billion.

  • Among major emerging economies, consumer credit markets are large and growing rapidly. In Brazil, total household lending reached R$4.4 trillion (roughly $850 billion) in late 2025, growing at around 12% annually. In China, total household debt, including mortgages, reached approximately $12 trillion as of early 2026, equivalent to around 60% of GDP. In India, household debt reached approximately $682 billion as of early 2025, representing around 17.6% of GDP, with non-housing retail loans now accounting for the majority of that total.

Given its importance, consumer credit is exactly the kind of system that should evolve to address weaknesses, correct limitations, and produce better outcomes for consumers. And it has evolved over the years. The FICO scoring system, for example, started as an effort to standardize borrower assessment and make lending less discretionary. The effort paid off: by making creditworthiness more objective and legible across a large and diverse borrower population, FICO helped scale consumer credit considerably and remains the dominant metric lenders use to determine who gets a loan and at what terms.

But the FICO model has limitations that are becoming increasingly hard to ignore. The Federal Reserve estimates that roughly 32 million American adults cannot be assigned a reliable credit score: around 7 million are "credit invisible," meaning they have no credit history at all, while roughly 25 million have "thin files," meaning they have some credit history but not enough for their score to be trustworthy. People in either category, as well as those with low scores, usually cannot access credit or can only access it on unfavorable terms: higher interest rates, shorter repayment periods, and stricter collateral requirements. The costs fall on both sides: capable borrowers get misclassified and locked out of the credit system, while lenders forgo demand from significant parts of the borrower population. And because access to credit is closely tied to purchasing power and economic mobility, the exclusion carries real socioeconomic costs for the individuals and households that credit could otherwise support.

As awareness of FICO's limitations spreads, the consumer credit industry is beginning to look beyond the credit score. Lenders are incorporating alternative financial data (e.g., cash flow) and non-financial data (e.g., education and employment) into borrower assessments, rather than relying on credit scores alone. Research on fintech underwriting shows that lenders using alternative-data models were able to identify "invisible primes" (borrowers with low credit scores or thin files but statistically less likely to default), analyze risk more precisely, and improve their returns by approving loan applications that traditional lenders would incorrectly reject. The Federal Reserve has made a similar point from a policy perspective, suggesting that chartered institutions could use cash flow data to assess repayment capacity when underwriting small-dollar loans, rather than basing creditworthiness evaluations on bureau-reported scores.

But some lending platforms are going even further than supplementing bureau-reported credit scores with alternative data. These platforms generate their own real-time financial data on borrowers and can observe a borrower's financial health more directly than a credit bureau can. Cash App is a good example. Cash App Borrow offers small loans (between $20 and $500), with an average loan size of $153, and approves loan requests based on analysis of borrower behavior inside the Cash App ecosystem. The model evaluates a user's aggregate deposits, transfers, spending, savings, balances, and retail investing activity within Cash App; installment payment history in Afterpay; and prior loan repayment history in Borrow. Over 70% of Cash App Borrow users have FICO scores below 580, a population traditional lenders would largely reject, yet the product maintains a 97% repayment rate. Block's own testing found that removing bureau scores from the model actually increased approvals by 38% without increasing losses.

SoFi is another example, although with a slightly different design; it still uses FICO scores, but also analyzes free cash flow, individual attributes (e.g., employment and education), and activity across the SoFi platform (including investing, savings, and insurance) when underwriting loans. Unlike Cash App, SoFi targets affluent borrowers with limited credit histories and focuses on large-dollar loans. Borrowers can borrow between between $5,000 and $100,000, with an average loan amount of $33,000 (much higher than Cash App's average of $153), and approved borrowers usually have a mean FICO score of 746 and a mean income of $158,000 according to SoFi’s reported data. SoFi's model uses free cash flow analysis to assess borrowers based on their actual financial position, rather than the length of their credit history, targeting borrowers who earn well and manage their finances responsibly but have not had time to build a thick credit file. Young professionals, recent immigrants, and anyone who simply has not used much credit fall into this population.

SoFi goes further by analyzing future earnings when serving another segment of the borrower population: individuals with limited credit history and moderate income but strong earning potential. Such borrowers may appear to be a credit risk to traditional lenders, especially if their debt-to-income ratio is high, but SoFi treats them differently. The insight is simple: a medical resident earning $60,000 may not pass a straightforward cash flow test today, but has a 97% probability of becoming a doctor and earning significantly more within a few years, making them a low-default risk despite modest current income and limited credit history. SoFi's unique underwriting model has made it one of the biggest success stories in the credit industry today: in Q4 2025 alone, SoFi originated a record $10.5 billion in loans across personal ($7.5 billion), student ($1.9 billion), and home lending ($1.1 billion), with cumulative net charge-off rates on personal loans tracking well below its 7-8% maximum tolerance (i.e., the maximum level of loan losses it is willing to accept).

Both Cash App and SoFi hint at the next big thing in consumer lending: closed-loop lending ecosystems that evaluate creditworthiness using alternative financial and non-financial signals, enriched by internal platform data and proprietary algorithms that other lenders cannot access. The shift away from traditional FICO scores is real and consequential. It can broaden access to credit for borrowers and improve risk management for lenders by providing a more holistic view of repayment capacity when underwriting loans, thereby making consumer lending more profitable and sustainable. But underwriting is just one part of the stack, and improving it does not automatically improve the rest of the system. A genuine improvement in consumer lending requires upgrading the entire stack, not just the part that decides who gets a loan.

Why better underwriting is not enough

Here is a simplified description of the consumer lending process: a borrower applies for a loan, the lender evaluates the borrower, approves or rejects the application, prices the loan, and sends the money; the borrower repays the loan over time, and the loan is closed once the borrower has repaid the principal and all accrued interest. Although somewhat accurate, the description omits a great deal of what actually happens between when a borrower applies for a loan and when the loan is fully paid off. A functional consumer lending system involves:

  • Origination: Verifying borrower identity, screening for fraud and sanctions compliance, assessing creditworthiness and repayment capacity, evaluating applications against internal risk and policy constraints, and generating approved loan offers with specific terms.
  • Underwriting: Modeling default probability, pricing risk, and determining loan terms, limits, and conditions based on borrower assessment and lender policy.
  • Servicing: Managing repayment schedules, ingesting payment events, handling partial and missed payments, updating loan status, processing disputes, tracking cure periods, managing delinquency, triggering enforcement, and maintaining performance histories.
  • Loan packaging: Aggregating loan performance data, enabling portfolio monitoring, and packaging loans into a form that outside investors can finance or purchase, allowing lenders to recycle capital and continue originating new loans.

The system is complex and has many moving parts, but fragmentation is the bigger problem. Consumer lending is fragmented in that the key functions (origination, underwriting, servicing, and loan packaging) are typically handled by separate entities and run on different platforms, with little coordination or shared logic among them. As a result, improvements rarely compound across the stack:

A lender can upgrade its underwriting model and still inherit mediocre servicing, and a servicer can improve its collections infrastructure while working on loans that were poorly originated. By the time loans reach the packaging stage, the weaknesses accumulated across origination, underwriting, and servicing are already baked into the underlying records: no amount of packaging sophistication can make a loan with an unreliable or opaque history attractive to financiers. Innovation keeps happening at different points, but the gains remain local, and consumer lending as a whole remains a fragmented and limited system despite producing smarter components over time.

Fragmentation has another consequence: increased coordination overhead. When critical workflows depend on integrating too many disparate systems, they become harder, or even impossible, to execute as integrations grow more complex, brittle, and expensive. Straightforward improvements that require buy-in from multiple providers stall because the stack cannot coordinate tightly enough to synchronize upgrades. This is particularly relevant for small-dollar lending: small loans are not unattractive because demand is absent or because borrowers are unfinanceable; they are unattractive because origination, monitoring, servicing, and enforcement are too expensive and too operationally heavy relative to the economics of the product. When the cost of the backend is high enough, some forms of lending become uneconomic even when real borrower demand exists.

Cash App illustrates this directly. The underwriting for Cash App Borrow runs on data generated by users inside the platform: Cash App Card spending, purchases at Square merchants, P2P transfers and deposits, Afterpay BNPL payment activity, and Borrow loan repayment history. Ditching the credit score in favor of behavioral data is a meaningful innovation, but the deeper reason the model performs as well as it does, despite operating in a sector long considered unprofitable (small-dollar loans) and serving borrowers traditionally seen as high-risk (subprime), is that Cash App controls more of the lending stack than a conventional lender does. It handles more of the borrower information gathering, assessment, underwriting, servicing, enforcement, and performance history tracking in-house rather than outsourcing those functions to separate providers.

SoFi illustrates the same logic applied to a different segment and a different degree of integration. Although it uses bureau-reported credit data, it layers free cash flow analysis and member-level platform data on top of it. SoFi's own data suggest that existing members benefit from higher approval rates, reflecting the depth of behavioral data the platform accumulates before making a lending decision. The advantage is not only that SoFi uses better data; the real advantage is that SoFi owns the data because it controls more of the borrower relationship by offering a full-stack financial services platform, which is a form of integration even if it falls short of owning the full lending stack end-to-end.

For context, SoFi members have access to a range of services beyond borrowing, including digital banking (SoFi Money), investing (SoFi Invest), credit cards, and insurance. Based on SoFi's publicly reported product counts (20.2 million total products, including approximately 2.5 million lending products, as of Q4 2025), the ratio of financial services to lending product usage is roughly 7x, meaning the average member uses around 7 non-lending products before taking out a loan. That depth of prior engagement gives SoFi a richer view of a borrower's financials than any credit bureau can provide. By the time a member applies for a loan, SoFi has often already seen months of deposit behavior, spending patterns, investment activity, and loan repayments, giving it a clearer picture of their financial health and likelihood of repayment.

Although both Cash App and SoFi use better scoring models, their real edge comes from controlling more of the data and processes that matter across the lending lifecycle. But those advantages are platform-specific and cannot be replicated by lenders who do not own a similar closed ecosystem. The broader opportunity is to build infrastructure that gives any lender access to valuable borrower data and the ability to coordinate origination, underwriting, servicing, and loan packaging within a single system, without requiring every lender to build a closed platform from scratch or to own the customer relationship end-to-end.

Integrating disparate functions inside a unified system is useful when those functions are complementary in production. Complementary functions reinforce each other's value (improving one raises the value of improving the other) and produce more value when composed together than they do in isolation. For example, an electric vehicle (EV) company that integrates vehicle manufacturing and battery production benefits from both functions reinforcing each other: improvements in battery design enable better cars, and better cars create more demand for better batteries. The combined system also produces cheaper inputs (sourced in-house rather than from external suppliers), higher quality outputs (car and battery designs can be co-optimized), and more value for both the manufacturer and the buyer than either function could generate independently.

A lender could follow a similar approach, integrating the key functions of the lending process into a single platform, thereby reducing fragmentation and coordination costs. It could unlock capabilities and workflows that are difficult to support or provide cheaply when every function sits behind a different interface and is managed, optimized, and priced by a different provider. This kind of integration has so far required building a closed platform from scratch, which most lenders cannot do. But there is another path: a lender can run on already integrated infrastructure, which provides most, if not all, of the benefits of building a closed ecosystem without requiring every lender to build one.

This is where blockchains become relevant. When the services that matter most for lending, such as access to real-world data, automation, and private and verifiable computation, are embedded directly into the blockchain as native protocol features rather than outsourced to external providers, the chain becomes a robust backend for real-world financial products like consumer credit. 

The common argument for bringing consumer lending onchain is that lower transaction costs (i.e., cheap gas fees) can reduce overhead for lenders and make certain types of lending, such as small-dollar lending, more feasible. The more compelling argument, however, is that lenders can build on integrated blockchain infrastructure and gain access to a shared execution layer with programmable logic, auditable state transitions, and native services that directly support consumer credit workflows. Because this infrastructure is open and permissionless, any lender can build on it and create their own integrated credit platform without having to construct a closed financial ecosystem from scratch.

Why and how to bring consumer lending onchain

Stripped of jargon and hype, blockchains are distributed ledgers: shared record-keeping systems maintained collectively by a network of nodes. State transitions are explicit and verifiable; each node independently executes every proposed change against its copy of the ledger and confirms the result before the new state takes effect. This requires all transaction data to be publicly available, since verification is impossible if a node can withhold the underlying data, which is why blockchains are transparent by default. A programmable blockchain adds an execution layer on top, enabling operations that execute arbitrary logic before updating the ledger, with correctness enforced by the network rather than a single administrator.

For a lending stack, those properties are useful in specific and concrete ways. Shared data access helps when origination, servicing, enforcement, and downstream reporting need to reference the same loan history. Explicit, verifiable state transitions help when disputes, delinquencies, repayments, restructurings, or defaults change a loan's status over time. A programmable execution environment helps when lending logic should automatically react to defined conditions rather than depend on manual intervention or external scripts. A legible system of record helps when loans eventually need to be monitored, financed, or pooled, providing enough clarity for credit financiers to reason about the integrity and quality of the underlying loans rather than take lenders at their word.

That last point is where offchain integration, however well executed, runs into a structural ceiling. A vertically integrated lender like Cash App or SoFi can reduce coordination costs and synchronize upgrades across its stack, but its records remain legible only to the degree it chooses to expose them. In practice, this means:

  • State changes are visible only to the system administrator, and loan lifecycle events cannot be independently verified by external parties.
  • Loan performance data is made available to outside investors through periodic, lender-produced reports rather than through real-time, continuously verifiable records.
  • Capital providers rely on the lending institution's reporting rather than directly inspecting the underlying assets when loans need to be financed or pooled.

A shared ledger with shared data access, programmable execution, and explicit, independently verifiable state transitions addresses each of those limitations:

  • The loan's history is legible to all parties with access to the blockchain without anyone having to vouch for it.
  • The lending system natively encodes business logic and automatically executes workflows based on defined conditions.
  • The quality and performance of loans can be evaluated directly and independently instead of relying on the lender's reporting.

This is what onchain infrastructure adds to the integration argument; it also answers the question of why an integrated offchain lending backend is not enough. Building one, as Cash App and SoFi have done, requires massive scale, a large existing user base, and significant capital investment in product infrastructure, which most lenders do not have. And even if an offchain lending system were perfectly integrated, it would still lack the legibility, programmable execution, and independently verifiable state transitions that a good lending system requires.

Low gas fees are a genuine improvement and matter especially for small-dollar lending, where backend operating costs can entirely overwhelm the product's economics. But low fees alone do not help unless the underlying blockchain also integrates execution with other critical functions. Most onchain lending today is built around overcollateralized models: a borrower locks up crypto assets worth more than the loan, and the protocol liquidates the collateral if the position becomes undercollateralized. That model works reasonably well for crypto-native users who hold digital assets and want liquidity without selling them. It does not work for the vast majority of real-world consumer lending, which is unsecured, depends on borrower assessment rather than collateral evaluation, and involves workflows that most blockchains are not equipped to support, such as origination, underwriting, compliance, servicing, and enforcement.

Many designs for bringing real-world finance onchain assume the blockchain handles execution and state management while outsourcing critical functions to middleware providers. An unsecured lending system built on existing blockchain infrastructure, with few or no native integrations, would face the same problems as traditional lending systems: high coordination overhead, brittle integrations, and lower product quality and cost efficiency due to reliance on too many third-party providers. The onchain system might be marginally better due to increased transparency and lower transaction costs, but it would not address the structural bottlenecks facing consumer credit or provide enough value to borrowers and lenders to justify the switching costs.

The question is not whether to move unsecured consumer lending onchain; it is what kind of blockchain infrastructure can actually support it. To answer that, we need to understand the workflows a functional unsecured lending system must implement and what it requires from the backend that powers it.

What does onchain unsecured lending look like?

Unsecured consumer lending involves a sequence of workflows that do not disappear because the application is running on a blockchain rather than a company server or a cloud service: borrowers still need to be identified and assessed; compliance checks still need to run; loans still need to be serviced and enforced; and lenders still need to package loans and aggregate performance data for downstream financing. The backend may change, but the workflows remain the same.

Understanding these workflows gives us a clearer picture of what the ideal blockchain environment for unsecured lending looks like: it is one where these workflows are supported natively, bundled into the execution environment itself, rather than assembled at runtime from a patchwork of third-party integrations. Each of the following workflows has its own requirements and its own failure modes, and getting any one of them wrong has consequences that ripple throughout the system.

Origination and borrower assessment

Before a lender can extend a line of credit, it must answer a basic question: should it lend to this person, and, if so, on what terms? Origination provides the answer to that question and covers identity verification, fraud screening, sanctions and compliance checks, creditworthiness assessment, policy evaluation, and offer generation. The output of origination is either a rejection of the loan application or a live, priced loan offer that the borrower can accept.

The quality of that output depends almost entirely on the quality of the inputs. A creditworthiness assessment is only as good as the data feeding into the model; a sanctions screen is only useful if it pulls from up-to-date lists; and a compliance check only serves its intended purpose if it evaluates the correct attributes and policies. Hence, origination is partially a data problem: the decision is only as good as the information available to make it.

Data access is where most onchain lending systems have historically been weakest. Blockchains are closed execution environments by default (they can only act on data already written to the chain), so onchain lending protocols have to make do with data already available onchain (e.g., collateral assets) or rely on oracles to pull real-world data and make it available to onchain programs. This approach has limitations: using onchain data works only for overcollateralized lending, and using oracles introduces additional points of failure, increases integration overhead, and reintroduces the fragmentation problem.

Data access matters especially given the shift toward alternative data models for assessing borrowers and underwriting loans. A blockchain-based unsecured credit platform that cannot pull a credit file, verify income, check employment and education history, or retrieve cash flow data when evaluating loan applications is working with a fraction of the information that modern credit platforms use to make better underwriting decisions. Improving data access requires a reliable mechanism to pull verified external data into the execution environment at origination time, with additional support for authentication (approving calls to external APIs using confidential credentials) and attestation (verifying that the data was correctly sourced and that any computation on it was carried out as specified).

Compliance and privacy-preserving decisioning

A lender that extends credit indiscriminately does not stay a lender for long. Access to credit is a product of decades of legal, financial, and institutional development, and that development includes a set of rules about who is eligible to borrow. Lenders are required to screen applicants against sanctions lists, check for criminal histories that would make a borrower ineligible, verify identity, and comply with jurisdiction-specific eligibility requirements. These are conditions for operating a lending product in the real world, not optional features a lender can implement at its own discretion.

The rationale is straightforward: credit is a form of economic capacity, and society has a legitimate interest in ensuring it does not flow to people who would use it to cause harm. A sanctioned individual who can borrow freely, or a fraudster who can access credit under a false identity, represents a failure of the system to protect itself. Compliance is how the system enforces those boundaries.

At the same time, compliance processes handle sensitive personal data, and borrowers retain privacy rights even during evaluation. A lender may need to know that an applicant is not sanctioned without being entitled to broadcast that applicant's identity and financial history to the world. This creates a specific requirement: compliance processes must reach correct, auditable conclusions without leaking the underlying data used to reach them. We call this privacy-preserving compliance.

The decision-making process carries the same requirement. Whether a lender evaluates a borrower using credit scores or alternative data like cash flow, spending patterns, employment history, educational background, and platform activity, the borrower must have a guarantee that those inputs remain private. The computation must occur within a protected execution environment: inputs go in, a verifiable decision comes out, and the underlying data is never exposed.

A public blockchain, where all inputs to every transaction are visible by default, cannot satisfy this requirement without a native mechanism for confidential computation. Pushing the sensitive logic offchain solves the privacy problem but reintroduces the opacity and trust assumptions that made the onchain approach attractive in the first place.

Servicing and enforcement

Origination produces a loan, but servicing keeps it running. From funding to final resolution, a lending system must track every payment event, update the loan status accordingly, handle exceptions, and execute the appropriate response at each stage. It helps to think of a loan as a state machine: the loan exists in a defined state at any given moment and moves between states according to rules triggered by specific events.

A loan may be active if the borrower makes payments on schedule, delinquent if the borrower misses a payment, and in default if the borrower fails to resume payment or pay off the loan before the cure period elapses. These state transitions must occur in a timely fashion: if a transition occurs late or not at all, the loan's record diverges from reality, with downstream consequences for risk management, regulatory compliance, and the credibility of the portfolio.

Enforcement occurs when servicing is blocked by a borrower's refusal to make timely repayments. When a borrower stops paying, and the cure process has been exhausted, the credit system moves into recovery: escalating to collections, triggering litigation, or executing whatever enforcement actions are necessary to recover the loan. In a fragmented consumer lending stack, each step in the enforcement process depends on external actors monitoring loan states and manually triggering the next action, introducing delay, inconsistency, and operational overhead, and creating points of failure that make loan records unreliable.

An integrated backend for onchain lending treats the entire loan state machine as native execution logic: conditions that trigger each transition are encoded directly into the system, and the associated actions execute automatically when those conditions are met. As a result, servicing runs automatically, and enforcement executes deterministically, without depending on external tooling or third-party providers.

Loan packaging and downstream financing

A lender that originates loans and holds them on its own balance sheet indefinitely is constrained by the size of its own capital base. To keep lending at scale, lenders need a way to recycle capital: sell loans or loan portfolios to investors, use them as collateral for financing, or pool them into structured products that can be sold to capital markets. This is loan packaging, and it is what connects the origination side of lending to the broader financial system that funds it.

The feasibility of packaging depends entirely on the quality and legibility of the underlying loan records. Outside investors need to understand how loans were originated, what underwriting standards were applied, how the portfolio has performed, and how servicing and enforcement were handled when things went wrong. If origination data is scattered, servicing history is hard to inspect, and state changes are opaque, due diligence becomes expensive, pricing becomes imprecise, and some portfolios simply cannot be financed at reasonable terms because the records are too unreliable to support credible underwriting from the capital side.

A lending system that produces clean, coherent, auditable loan histories changes this dynamic. Loans with legible origination records, complete servicing histories, and transparent state transitions are easier to monitor, pool, and finance. The asset becomes more credible to outside capital because historical data can be independently evaluated, and no one has to vouch for its integrity. Downstream financing and secondary market activity are grounded in the real performance of the underlying loans rather than the reputation of the institution holding them.

Tokenization is sometimes described as the goal here, but it is more accurately a byproduct. For a token tied to a portfolio of unsecured loans to represent something real and accrue actual value to tokenholders, the portfolio must comprise high-quality loans with correct originations, good performance, effective servicing, and reliable enforcement. A bad loan portfolio does not magically become better just because it is tokenized, so focusing on tokenization alone puts the cart before the horse.

Rialo as an integrated backend for unsecured consumer lending

The workflows described above set a clear bar that an infrastructure backend for unsecured lending products running onchain must meet. That backend must have native data access for origination, privacy-preserving computation for compliance and decisioning, automated execution for servicing and enforcement, and a shared, auditable system of record for loan packaging and downstream financing. Rialo is designed around exactly those requirements and offers each of them as integrated protocol features, consistent with Rialo's supermodular design philosophy, which holds that features complementing execution should be integrated into the base layer rather than delegated to middleware.

Native data access for origination

Origination often depends on real-time external data that most blockchains cannot access natively. Rialo addresses the need for lending systems to access real-world data by offering native web and API calls as an integrated protocol feature. Native web calls allow onchain programs to retrieve data from external sources during execution without routing the request through a third-party service. An unsecured lending platform on Rialo can call a credit bureau, a KYC provider, a bank data aggregator, or any other data source with an API; retrieve the relevant borrower information; and feed it directly into the origination workflow at execution time.

For data that requires stronger guarantees, Rialo's native oracle infrastructure provides access to validator-attested data feeds. When a lending application relies on real-world data, particularly financial data, as inputs to an underwriting model, it requires a verifiable guarantee that the data was properly sourced and has not been tampered with. Rialo's native oracle enables validators to attest to the provenance and correctness of retrieved data, with validators losing their bond if they produce incorrect attestations, making the attested data trustworthy enough to base a loan decision on.

Together, these two capabilities give a lending application on Rialo the data-access infrastructure that origination actually requires: flexible enough to pull borrower-specific information from any external source, and rigorous enough to attest to the provenance of the inputs that underwriting models depend on.

Private computation for compliance and decisioning

Compliance and decisioning require a specific combination: outcomes that are verifiably correct and inputs that are never exposed. Rialo addresses this through REX (Rialo Extended Computation), a private execution environment integrated directly into the protocol. REX allows onchain programs on Rialo to operate on sensitive inputs and produce verifiable results while keeping input data private. A third party can confirm that REX produced a valid result without observing the underlying data or computation.

This is possible because sensitive inputs, such as a borrower's financial records and personal information, are encrypted before submission, decrypted within REX, processed according to the program's logic, and cleared from memory after execution completes. The result is then published onchain with a cryptographic proof that the computation was carried out correctly, without the underlying inputs ever appearing in the clear. What emerges is private and verifiable computation, which directly enables the kind of privacy-preserving compliance and decisioning that unsecured lending requires.

For compliance, a lending application can evaluate sanctions status, run eligibility checks, and enforce jurisdiction-specific rules entirely within REX. The outcome is recorded onchain and auditable, while the borrower's personal data and the intermediate states of the computation remain private throughout. For decisioning, the same architecture applies: a lender using traditional signals (credit scores) and alternative signals (cash flow data, education, employment history) can run that assessment inside REX, producing a correct and verifiable credit decision while keeping every input invisible to anyone outside the private execution environment.

Automated servicing and enforcement

Relying on external actors to monitor loan conditions and trigger state transitions introduces delays, inconsistencies, and points of failure that make the loan record unreliable. Rialo eliminates dependence on middleware for servicing and enforcement by offering automation as a protocol-native feature. Native automation on Rialo is powered by conditional transactions: a conditional transaction (also called a reactive transaction) is automatically executed by the network once certain user-defined conditions are satisfied.

A consumer credit system can use conditional transactions to encode the entire loan state machine natively, with trigger conditions tied to loan lifecycle events. This makes it possible to automate servicing and enforcement workflows and remove third parties from the critical path entirely. For example:

  • A missed payment triggers a delinquency flag
  • A cure period expiring triggers escalation and review
  • A default condition triggers enforcement

In each case, the required onchain actions execute automatically without an admin or external actor (e.g., bot, keeper, or relayer) having to orchestrate it. The scheduled conditional transactions inherit the same guarantees as regular transactions, so they execute deterministically, securely, and reliably. Since loan records are updated automatically, the loan's state reflects actual reality, and the servicing record is more trustworthy because the logic is encoded inside the application itself rather than in an external bot or scheduler. The state transitions are deterministic and auditable, and they cannot diverge from the rules the operator originally defined.

Shared state access and downstream financing

Downstream financing of consumer credit depends on the quality and legibility of the historical records associated with a loan. When origination, compliance, servicing, and enforcement all run on Rialo and produce state changes recorded on the same ledger, the full lifecycle of each loan is captured in a single coherent record.

A loan's history, from application through final repayment or default, is auditable by any party with access to the chain, meaning outside capital can assess the asset directly rather than take the institution's word for it. Pooling, monitoring, structured financing, and secondary market activity all become more credible when the underlying loan histories are inspectable, consistent, and produced by deterministic logic rather than manual processes. The record speaks for itself, which is what makes due diligence credible and enables downstream financing on reasonable terms.

Conclusion

The future of consumer lending is bigger than better underwriting. Better underwriting matters, and the shift from relying on FICO scores to incorporating alternative data into borrower assessment is important. But consumer lending is currently a fragmented system, which means improvements in one area do not reliably compound. Fragmentation also increases coordination costs, makes workflows brittle and expensive, and causes the overall system to underperform relative to its individual parts.

A more serious and important goal is to upgrade the consumer lending stack as a whole. That means focusing on integration first, because complementary functions produce more value when they improve together, and fragmenting the stack creates a tax that impedes innovation and growth. It means focusing on onchain infrastructure next, because integration alone does not provide shared state access, auditable state transitions, programmable execution, and other properties that the ideal consumer lending application requires. The output is a robust, integrated financial backend that can power unsecured lending systems at scale with positive outcomes for lenders, borrowers, investors, and other stakeholders in the consumer credit market.

At the start, we asked why improving underwriting was not enough. The answer, built from first principles throughout this article, is that fixing consumer lending is a systems problem. The real goal is to develop an integrated infrastructure that lenders can use to build more coherent lending products, improving how every workflow in the lending lifecycle, from origination and compliance to servicing and loan packaging, actually functions. It is a more ambitious goal than optimizing one layer of the consumer credit stack. It is also the right one.