The explainability requirement in credit scoring is often framed as a regulatory burden. Lenders and scoring providers accept it as a compliance cost and implement the minimum needed to satisfy disclosure obligations. We think this framing is wrong, and we designed Panthera's output format around a different view: that reason codes are a core product feature, not a compliance add-on, and that the quality of the reason codes is as important as the predictive quality of the score itself.
This piece explains why we believe that, what the practical difference is between a genuine reason code and a post-hoc rationalization, and what it means for a thin-file borrower in Vietnam or Indonesia that the reason code they receive connects directly to the model's actual decision logic.
Two Types of "Explainability"
There's a distinction that doesn't get discussed enough in the credit scoring industry between explanations that describe what the model actually did and explanations that are generated separately to satisfy a disclosure requirement.
Post-hoc rationalization works like this: a complex model (a deep neural network, or a highly tuned ensemble) makes a credit decision. A separate, simpler explanatory mechanism is then run to generate a human-readable reason code. The reason code is plausible and roughly consistent with the score direction, but it wasn't actually part of the decision logic. LIME and similar post-hoc explainability methods produce outputs of this type. The reason code says "your income regularity score was a negative factor" because the explanatory model's local approximation suggests that, not because the underlying model explicitly computed and weighted income regularity in a directly traceable way.
Native explainability works differently. The model architecture and feature engineering are designed from the start so that the driving features behind a score can be directly extracted. Gradient boosting models with explicit feature importance, trained on interpretable engineered features, allow reason codes that correspond to the actual computational pathway. Feature attribution in these models is not approximate: when the model says income regularity was a top-three driver, that reflects the actual feature contribution computed during scoring, not a post-hoc approximation.
Panthera's models use the second approach. The three reason codes returned on every scoring decision are extracted from the model's actual feature contributions during inference. This is not a description of our ambition. It's a description of the specific architectural and engineering choices we made and their operational consequences.
Why It Matters for Thin-File Borrowers Specifically
For a borrower with a full bureau history who gets a credit score, the reason codes returned on a decline are likely to reflect something the borrower already knows. "Previous missed payment" or "high utilization on existing revolving credit" point to facts the borrower can verify and potentially address. The reason code serves the regulatory disclosure function and also gives the borrower actionable information.
For a thin-file borrower, the situation is different. The scoring decision is based on behavioral data the borrower may never have thought of as credit-relevant. A reason code that says "income regularity below scoring threshold" is technically correct but not actionable without more context: what does income regularity mean? What data was it computed from? How much below the threshold?
We've been designing our reason codes around what a credit officer explaining a decision to a borrower would actually say. The production reason codes we return include the feature name, the direction of impact, and where possible the magnitude relative to the population the borrower was scored against. "Your utility payment timing has been inconsistent over the past 90 days" is a more useful reason code than "behavioral factor negative." It connects the borrower's actual behavior to the decision in a way they can understand.
This is harder to build than it sounds. It requires that the underlying features be defined at a level of abstraction that produces human-readable names without losing the specificity of what was actually computed. "Income regularity" is human-readable but doesn't tell the borrower whether the issue was variability in income amount or variability in when income arrives. We've had to iterate on feature naming and description to find a level of abstraction that's both accurate and interpretable.
The Operational Case for Reason Codes
Credit officers at lenders using our scoring product make override decisions. A score below the approval threshold with a reason code that says "utility payment cadence irregular - seasonal pattern detected" is a different override situation from a score below threshold with "multiple negative behavioral indicators." The first may warrant a manual review if the credit officer has context about that borrower's industry or seasonal income pattern. The second doesn't give the officer anything to work with.
We've seen this play out in practice. One lender operating in Vietnam found that a class of borrowers in the hospitality sector were systematically receiving lower scores in February and March due to seasonal income patterns around Tet. The reason code explicitly flagged "income inflow pattern shows seasonal reduction relative to 6-month baseline." That gave the lender enough information to institute a manual review path for hospitality-sector borrowers during those months. Without an explicit reason code, they would have seen a pattern of rejections and had to work backward to find the seasonal correlation themselves.
This is not just a loan officer convenience. It's a risk management capability. A lender that understands why its scoring tool is making specific decisions can calibrate overrides appropriately. A lender with a black-box tool and generic reason codes is flying partially blind on the segments where their override decisions matter most.
Regulatory Alignment Across Our Four Markets
All four markets Panthera covers have some form of disclosure requirement for credit decisions. The specifics vary, and we want to be precise rather than generalizing across very different regulatory frameworks.
In Japan, the Financial Services Agency's framework for money lending regulation requires that applicants who are declined receive a disclosure of the basis for the decision. The FSA's specific requirements are around what must be disclosed, not how it's technically generated. But the spirit of the regulation is that borrowers should be able to understand why they were declined. A reason code that says "behavioral factor below threshold" satisfies the form of that requirement without satisfying its spirit.
In Indonesia, OJK's consumer protection framework for digital lending requires transparent and fair treatment of borrowers, including disclosure of the basis for credit decisions. OJK has been increasingly active in enforcing responsible lending standards in the digital lending sector. Reason codes that are technically accurate but practically uninformative are a potential area of regulatory risk as OJK's supervision of this sector deepens.
In the Philippines, BSP guidelines on consumer lending include disclosure requirements. In Vietnam, SBV's framework continues to develop, but the direction is toward greater transparency and consumer protection in lending decisions.
We are not saying that any of these regulators have currently mandated a specific technical standard for reason code generation quality. We're saying that the trajectory of regulation in all four markets is toward more meaningful disclosure, not less, and building a product that already meets a higher standard is better long-term positioning than scrambling to upgrade when regulatory requirements catch up with practice.
The Limits of What Explainability Can Tell You
There's a counterpoint worth making. Explainability in a credit model that uses behavioral alternative data has inherent limits. The model is producing a probabilistic risk assessment based on behavioral patterns. It can tell a borrower that their income regularity was a negative factor. It cannot tell them with certainty that paying their bills more consistently will result in a higher score on their next application, because the model's prediction depends on the full feature set, not any single feature in isolation.
We include a coverage score in every output specifically to communicate the confidence level of the decision. A score built on 0.4 coverage of the standard feature set should be read differently from one built on 0.85 coverage. The reason codes for a low-coverage score may reflect the absence of data as much as the presence of negative signals. Borrowers and lenders both need that context.
The strongest reason code we can return is one that accurately describes a real feature that the borrower can observe and, over time, influence through their actual behavior. That's what we've optimized for. Not the minimum compliance standard, and not a claim that reason codes answer every question about why a borrower received a particular score. But a meaningful, accurate, and operationally useful signal that connects the model's decision to the borrower's financial life in terms they can act on.
