Understanding a User’s Decision Data

When a borrower applies for a loan on your platform, the system doesn’t just return a yes or a no. It runs the applicant through a series of structured checks and scoring processes, then compiles everything into what is called decision data. Before approving or declining any loan request, reviewing this data gives you a clear picture of exactly how the system evaluated the borrower — and why it reached the conclusion it did.

What is decision data?

Decision data is a record of all the checks and scores generated by the system when evaluating a borrower’s loan request. It is produced by the Oraculi decision engine, which processes the rules and modules configured in your decision model and returns a structured output based on the results.

This data is not just available for approved or eligible requests. It is also generated for failed or ineligible requests, making it a useful tool for investigating why a borrower was turned down and determining whether any manual review is warranted.

The four sections of a user’s decision data

Decision data is organized into four main sections, each surfacing a different layer of the evaluation.

General details

This is the high-level summary of the loan evaluation. It tells you at a glance whether the borrower passed or failed the overall assessment. Specifically, it shows:

The pass status, which returns either true or false
The overall decision, which shows as either eligible or not eligible
The decision engine used, which is typically Oraculi
The borrower’s credit score, calculated by the scoring module within the decision model

This section gives you an immediate read on the outcome without having to dig into the individual checks.

Offers

If a borrower is deemed eligible, the offers section displays the loan offer generated by the system. This is based on the borrower’s request and the configuration of the decision model, including the offer settings defined for that loan product. The offer amount shown here reflects what the system has determined the borrower qualifies for under your configured rules.

Oraculi

This is the core of the decision data. The Oraculi section shows the individual checks the borrower went through as part of the decision model evaluation. These checks run sequentially, meaning that if a borrower fails one module, the process stops at that point and subsequent checks are not run.

For example, one of the checks within Oraculi is the Karma check, which verifies whether a borrower has been flagged on the Lendsqr network for defaulting or fraudulent behavior. If a borrower fails the Karma check, the system will not proceed to the next module.

Each check in the Oraculi section is color-coded to make interpretation fast. Red indicates a failed check, while green indicates a passed one. You can expand each section using the Show more button to see the specific attributes evaluated and their individual outcomes. This drill-down view makes it easier to identify exactly which data point caused a failure, rather than just knowing that a check was not passed.

The raw data behind the entire evaluation can also be accessed by selecting Show raw data, which returns the full output in JavaScript Object Notation format for more technical review.

Please note that the raw JSON data can also be seen by choosing the ‘Show Raw Data’ button.

Reasons

If a borrower is ineligible, the reasons section displays the specific causes for the failed evaluation. Rather than relying on inference from the Oraculi section, this section surfaces the failure reasons directly, making it straightforward to communicate the outcome to a borrower or to investigate a disputed decision.

How to use decision data in practice

Decision data is most useful when you treat it as both an evaluation record and an investigation tool.

For routine approvals, a quick scan of the general details section is often sufficient. If the pass status is true and the offer section shows a valid loan amount, you have what you need to proceed.

For borderline or unusual cases, it is worth expanding the Oraculi section to review the individual check results. The system may have returned an eligible result, but you might notice that certain checks returned values you consider unacceptable, such as a credit score that just barely passed the threshold. Decision data supports your judgment, not just the automated output — you can still choose to decline a request even when the system has returned an eligible outcome.

For failed requests, start with the reasons section to understand why the borrower was turned down. Then cross-reference with the Oraculi section to see at which module the evaluation stopped. This is especially useful when a borrower contacts you to dispute a decision, as it allows you to explain the specific reason clearly.

Common errors and what they indicate

If a borrower fails at the Karma module, it typically means they have been flagged on the Lendsqr network — either for loan default on another platform or for a compliance-related issue. This is not a system error; it is the decision engine working as intended.

If the decision data shows a failed status but the reasons section is empty, it may indicate a configuration issue with the decision model. In such cases, it is advisable to review the decision model settings on the admin console and confirm that all modules are correctly configured.

If the credit score is missing or not displayed, the scoring module may not have been included in your decision model configuration. You can add or adjust scoring modules by navigating to the decision models section of the admin console.

Best practices for reviewing decision data

Developing a consistent approach to reviewing decision data improves both the speed and quality of your loan decisions. Consider the following:

Review the general details section first to get the overall outcome before diving into specifics
Use the color coding in the Oraculi section as a quick diagnostic tool — a single red section can immediately direct your attention
For high-value loan requests, always expand the Oraculi section to review individual attribute outcomes, not just the overall module result
Keep records of any manual overrides you make after reviewing decision data, along with the reasons, for audit and compliance purposes
Revisit your decision model configuration periodically to ensure the checks being run still reflect your current lending policy