How Scoring Works
Every Hola Credit assessment is built from structured evidence, bounded by confidence limits, and produced by versioned deterministic code. This page explains what the assessment measures, how it is calculated, what it cannot prove, and how the policy versioning ensures that every result is traceable.
The Hola Credit scoring engine evaluates the cash-flow evidence in a borrower-authorised bank statement across seven components. Each component captures a different dimension of the applicant's financial pattern, and each carries its own confidence level based on the quality and sufficiency of the underlying data.
The income floor is the minimum reliable monthly income the statement can support. It is derived from the consistent credit transactions identified in the statement period, discounted for concentration risk and volatility. The income floor is not a prediction of future earnings — it is a conservative measure of what the statement evidence can demonstrate the applicant has earned. When the data is insufficient or the extraction confidence is low, the income floor may be null rather than a potentially misleading number.
Consistency measures how regular the applicant's income pattern is from month to month. A freelancer who receives similar amounts on a predictable schedule scores higher on consistency than one with large, irregular deposits separated by long gaps. This is not a judgement about which pattern is better — it is an observation about the predictability of the cash flow, which is relevant to a lender assessing repayment capacity. The consistency measure is derived from the number of active earning days, the frequency of income deposits, and the month-to-month variation in income totals.
Volatility captures the degree of fluctuation in the applicant's cash flow over the statement period. High volatility means that income and spending vary significantly from month to month, which may affect the applicant's ability to meet fixed repayment obligations. Low volatility indicates a more stable pattern. The volatility measure is calculated from the standard deviation of monthly net cash flow, adjusted for the statement length. It is presented as a numerical value, not a pass-or-fail threshold, because different lenders have different risk tolerances for cash-flow variability.
The trend component indicates whether the applicant's cash flow is improving, stable, declining, or uncertain over the statement period. It is calculated from the direction of change in monthly income totals, adjusted for one-off transactions that could distort the trend. A declining trend does not mean the applicant is uncreditworthy — it means the lender should consider whether the current cash flow is sustainable. An uncertain trend indicates that the data does not support a clear directional assessment, which may be the case for short statement periods or highly variable income patterns.
Concentration measures how dependent the applicant's income is on a single payer or source. An applicant who receives all income from one client is more concentrated than one who earns from multiple sources. High concentration does not inherently mean higher risk — a salaried employee is, by definition, concentrated in one employer — but it does mean that the loss of a single income source would have a disproportionate impact. The concentration measure is derived from the distribution of credit amounts across identified income sources.
Red flags are specific signals that the lender should review carefully. These include negative-balance occurrences, failed-payment indicators, loan-proceeds deposits that suggest existing debt obligations, and unusually large or atypical transactions that could distort the cash-flow picture. Each flag carries a severity level — information, review, or material — and is linked to the specific transactions that triggered it. Red flags are not a recommendation to decline; they are a recommendation to look more closely.
Data sufficiency indicates whether the statement provides enough information to support a reliable assessment. A statement that covers only one month, has many uncertain or low-confidence transactions, or contains significant gaps may be rated as limited or needs_review rather than sufficient. This is not a reflection on the applicant — it is a reflection on the quality of the evidence available. When data sufficiency is low, the assessment components may carry null values or wider confidence bounds, and the lender should weigh the evidence accordingly.
The Hola Credit scoring engine is deterministic. It does not use a machine-learning model to calculate the assessment — it uses versioned code with fixed rules. Given the same extracted transactions and the same policy version, the engine will always produce the same score, the same component values, and the same flags. There is no randomness, no hidden state, and no model discretion in the scoring step.
This is a deliberate design choice. AI is used in the extraction and categorisation phase — identifying transactions, normalising amounts, and assigning categories — but the scoring engine itself is a separate, deterministic process. The extraction model may produce slightly different results on different runs, and when it does, the extraction model version is recorded so that the variation is traceable. The scoring engine, however, is not subject to model variation.
The boundary between AI-assisted extraction and deterministic scoring is fundamental to how Hola Credit works. The extraction model identifies transactions in the bank statement, categorises them, and assigns confidence scores. These are the inputs to the scoring engine. The scoring engine then applies fixed, versioned rules to calculate the assessment. The AI never sets credit limits, adjusts policy weights, or makes lending decisions.
When the extraction model produces low-confidence results, the system flags the affected transactions for human review rather than silently including them in the assessment. The model gets no tools, no network access, and no secrets. Its output is validated against a strict schema, and any transaction that fails validation is treated as uncertain. This separation ensures that the assessment is explainable in terms of the rules that produced it, not in terms of a model's internal state.
The scoring policy is versioned and immutable once used. Every assessment records the policy version, the extraction model version, and the input data that produced it. When the policy changes — because the lender adjusts the weights, or because new evidence components are added — the change is recorded as a new version, and all subsequent assessments use the new version. Historical assessments are never retroactively recalculated.
This versioning is essential for auditability. If a lender needs to explain why a particular assessment produced a particular result, they can trace it to the exact policy version and the exact inputs. If the policy has since changed, the historical assessment still reflects the rules that were in effect at the time it was generated. The policy version is included in the assessment summary, alongside the extraction model version and the data quality indicator.
The exact policy weights require documented underwriter input and later calibration against repayment outcomes. They are not approved in this repository and should not be assumed to be final. The versioning system is designed to accommodate this evolution without compromising the traceability of any individual assessment.
Every Hola Credit assessment produces a structured summary that the lender can review, question, and use alongside their own policies. The schema below shows the fields included in the assessment output. This is a contract example, not application code — it describes the shape of the data, not the implementation.
type Assessment = {
scoreRunId: string
statementPeriod: { from: string; to: string }
dataQuality: "sufficient" | "limited" | "needs_review"
extractionConfidence: number
incomeFloorMinor: number | null
consistency: number | null
volatility: number | null
trend: "improving" | "stable" | "declining" | "uncertain"
flags: Array<{
code: string
severity: "information" | "review" | "material"
evidenceTransactionIds: string[]
}>
score: number | null
tier: string | null
scoringPolicyVersion: string
extractionModelVersion: string
limitations: string[]
}scoreRunId uniquely identifies the assessment run. statementPeriod defines the date range covered by the statement. dataQuality indicates whether the statement provides sufficient, limited, or review-needed evidence. extractionConfidence is a numerical value reflecting the reliability of the transaction extraction.
incomeFloorMinor, consistency, and volatility are the core scoring components. Any of these may be null when the data does not support a reliable calculation. trend indicates the direction of cash-flow change. flags are specific signals with severity levels linked to the transactions that triggered them.
score and tier are optional outputs that depend on the policy version. scoringPolicyVersion and extractionModelVersion ensure traceability. limitations lists the specific caveats that apply to the assessment, such as short statement periods, high concentration, or uncertain data.
At launch, the quality of Hola Credit's extraction can be measured against labelled statements, and the assessments can be compared with experienced human review. This provides a meaningful baseline: if the system extracts the same transactions that a skilled loan officer would identify, and if the assessment reflects the same cash-flow pattern that an experienced reviewer would describe, then the system is working as designed.
What the first score cannot prove is predictive accuracy against repayment outcomes. That calibration requires real pilot loans to be originated, repaid (or not), and the outcomes to be compared with the initial assessments. This process takes six to twelve months of seasoning before the results are statistically meaningful. Hola Credit does not claim predictive accuracy before that data exists.
The cold-start disclosure is not a limitation unique to Hola Credit — it applies to any new credit assessment tool that has not yet been validated against actual repayment outcomes. The difference is that Hola Credit states it explicitly, rather than implying predictive validity from extraction quality alone. The extraction quality target is that at least ninety-five percent of supported test statements complete parsing and categorisation without an unrecoverable pipeline failure. This is a format-processing target, not a claim of transaction-level accuracy or predictive power.
Post-launch, the long-run predictive metric will be defined and measured with qualified statistical and legal review. The system is designed to support this evaluation — every assessment is traceable to its inputs, its policy version, and its extraction model — but the evaluation itself can only begin after real loans have seasoned. Until then, the assessment should be treated as supplementary evidence, not as a validated predictor of repayment.
The assessment is designed to be explainable. If you want to understand how it would apply to your lending or retail credit workflow, pilot access includes full visibility into the evidence, confidence, and policy versions behind each assessment.