Domain expertise, bias auditing, and a tiered feature design behind VALID’s Real-time Loss Alerts model
In brief
A failed deposit and a charged-off deposit are not the same problem, and most decisioning stops before it tells an institution which of the two it is holding. Real-time Loss Alerts was built to score that difference. What follows is an account of the parts of the model that are difficult to reproduce. We dive into operational experience that help create our features, the rule that keeps the model from learning something we can’t defend, the reasons we whitelist legitimate some populations rather than failing them, and what we can and cannot deliver to an institution that does not have the data points the model was designed around.
Contents
1. A failed item tells you to stop. It does not tell you what you are facing.
2. One place for the data and the model
3. The features are the product
4. What a former teller knows that a statistician does not
5. Using an LLM as a second reader
6. Auditing for bias when you do not have the bias data
7. Whitelist before you decline
8. One Hundred base features, or twenty
9. If you are buying a loss model, ask these five questions
10. Where this leaves us
Real-time Loss Alerts, or RTLA, answers a question of the deposits we are already failing, which ones will end in money the bank never recovers?
A returned check is an inconvenience and a charge-off is a loss, but both outcomes arrive inside the same failed population and under the same decision code. Handling them identically costs an institution either in loss dollars or in customer relationships. RTLA separates them, which allows an operations team to spend its time on the flags that carry material exposure rather than distributing that attention evenly across a population where most of the exposure sits in a minority of the accounts.
What follows is an account of how my team builds and maintains that model beyond just the architecture, because architecture is the most easily reproduced part of any modeling program. The weight falls instead on four things that are not easily reproduced: the professional backgrounds from which our feature hypotheses originate, a standing rule that every input trace to a real loss reason, a preference for whitelisting legitimate populations rather than failing them, and the ongoing work of scaling the model down for institutions that cannot send us much data.
RTLA began as a companion to our core decisioning model that covers an enormous range of actual exposure. Using that core model you may have a returned deposit that was failed for instant funding. One end is a customer where the funds will be recouped, at the other is a customer who will walk away and leave a genuine charge-off behind. Both may arrive as the same decision code, and they carry very different consequences.
The gap we set out to fill sits inside that failed population. RTLA scores it and flags the accounts heading toward an unrecoverable loss, so that an institution can decide how to treat them. That may mean a longer hold, a route to review, a call to the customer, or continued monitoring of the account. The goal was never to add another stop sign it was to notify the institution, the same day, we may have real money loss on the line instead of finding out three weeks later.
That framing changes everything downstream of it, beginning with the target. A model built to predict returns will happily learn check amounts and seasonality, whereas a model built to predict loss has to learn something about the account and the person behind it. Those are different models even when they score the same transaction.
RTLA is built, trained, and scored in on environment alongside the data it runs on. Consolidating into a single environment did less for modeling itself than it did for the distance between having an idea and testing it. That distance turns out to matter more than it sounds like it should.
A good share of what makes the model work comes from interactions, which is our term for a feature built out of the relationship between other features. Under our previous setup every interaction had to be constructed by hand each time a model was trained and nothing built for one client’s model carried over to the next. A model carrying a hundred interactions also carried a hundred manual steps that had nothing to do with modeling judgment.
Those interactions now live in a catalogue we can reference no matter the client or analyst who made them. Before we limited it to a fixed and tested set for each client, now we have streamlined the process that encourages sharing and experimenting. Depending on what data points a client can send we can now reference a library of interactions that will only draw on the ones most essential for the model being built at that time. Streamlining the process so we can focus our priorities on innovation rather than one off data entry.
The result is that experiments became cheap which leads to more innovation. A material share of the improvements to this model originated in tests that would not have justified their setup cost under the old process, which is a different sort of benefit..
If I had to name the one thing that separates this model from a competent generic implementation, it would be the feature set rather than the algorithm. Anyone can pull a gradient-boosted classifier off the shelf but feature quality can pull one model over the others.
Early RTLA was calibrated toward the obvious bad actors, but obvious bad actors are also the cheapest fraud to catch. As the model matured the work moved toward the quieter categories like accounts that may have been taken over, and customers who look entirely healthy on paper while slowly coming apart. One of the more useful signals in that second category is about as unglamorous as it gets, namely an account with ten years of consistent good high dollar volume that has slowly declined in the past three to four months. Nothing about that account presents as fraud, the balance may still be reasonable and the transaction behavior still ordinary, but the income that would have supported a recovery is gone, and the loss exposure is no longer what it was last quarter.
A good share of that work comes from clients, and this is the part I wish more teams took seriously. When a client tells us that their losses are concentrated in some narrow, fringe segment we were not weighting heavily, that is not a complaint; it is a specific and testable claim about a portfolio they know more intimately than we do. We will then find the characteristics that isolate that segment and build them in as a new feature, an adjusted weight, or a new interaction. Client loss reporting is one of the cheapest source of good feature hypotheses available to us, and it is routinely wasted.
Ask me what differentiates model performance and I will not point at an algorithm; I will point at who is in the room.
My coworkers have prior backgrounds at credit unions, mortgage lending, and behind the teller line, and that last one matters more than it sounds like it should. Someone who spent two years as a teller has watched a person try to pass a bad check in person and knows which customer requests are ordinary and which ones are predatory. That is pattern recognition built out of thousands of real interactions, and it does not exist in any dataset we can buy.
There is an analogy I keep coming back to. Put a team of pure statisticians on hospital outcomes data and they will find real effects based on the patient numbers because the data is real. Put a nurse in the same room and she will tell you that hospitals with more laxed visit policies have patients that recover faster, something that may not be documented or used in data analysis until then. That insight is on the floor, and the only way to get at it is to have been there or to hire someone who was.
Most of our better features began as somebody’s recollection of how a specific fraud scheme worked, translated afterward into something we could measure across millions of deposits. The statistics come second, because a hypothesis must be articulated before anyone can test it.
Separately from the modeling platform, I use a private enterprise LLM deployment inside our own environment, not to generate ideas from scratch but to argue with the ones I already have.
My domain knowledge has a shelf life, and that is the honest problem this solves. I may unknowingly be fixated on a way fraud worked and was modeled three years ago or inside a bubble of reading up on the fraud experts I am familiar with. So I describe a scenario in detail, including the target, the weighting approach, and the data I have, and then ask what I am failing to account for. I use it to check whether two interactions are effectively measuring the same quantity, whether a query could be structured more efficiently, and whether there is recent published work outside my bubble bearing on an approach I have not tried. Sometimes I ask it to critique the way I asked the question, which is more useful than it sounds.
|
What that looks like A sanitized version of the kind of prompt I send: Setup: gradient-boosted model, a year of deposit-level data, a few million rows, a couple hundred candidate features. Target is unrecoverable loss, not return. Feature set is check-level attributes and velocity stats. Two things. Which of these interactions are redundant with each other, and which would you drop first? And if I assign cutoffs against a volume capacity target instead of a loss-rate target, what breaks in that logic? Do not confirm what I already have right. Tell me what I am missing. Note the shape of it: a concrete setup, narrow questions, and an explicit instruction not to be agreeable. A vague prompt returns a vague answer that reads well, which is worse than no answer at all. |
Figure 1. Illustrative prompt structure. No client data or proprietary feature definition goes into tooling of this kind.
It is a sounding board rather than an oracle, since it has no idea what happens at a teller window and does not replace the people who do, but it does catch drift in my own thinking, which is the failure I am least able to catch by myself.
RTLA does not receive protected attributes: race, gender, and age never reach us, so none of them can enter the model as an input. That sounds like it eliminates the bias, it doesn't, because a model does not need a protected attribute to end up targeting one. A model given enough geography, balance behavior, and specific transaction detail may approximate one without ever being asked to.
Every input must trace back to an actual loss reason that can withstand multiple population types. A feature does not earn a place because it only works in a specific location or it tested predictive in a way nobody can explain. If no one on the team can describe the mechanism connecting that feature to a loss, it stays out, whatever it does to the validation metrics. That rule applies even to a field as ordinary-looking as the zip code where a deposit physically occurred, if the model uses it at all: it stays in only because certain fraud patterns cluster at specific transaction locations, not because it happened to help the model's score.
Unexplainable lift is the most common way a proxy gets into a production model, and it always arrives looking like good news.
That admission rule governs what the model is allowed to learn from. It says nothing about how we check the model's output for bias, and that check runs on a completely separate field. Every account carries a home branch, assigned by the bank independent of where any single transaction happens to occur. We tie each account's outcomes back to that home branch, match the branch to publicly available Census data, and segment the resulting population into income tiers and race-concentration tiers. The model never trains on this field and never sees it at scoring time; it exists solely on the audit side, downstream of the model, as the lens we use to check whether the model's outputs land evenly across the tiers it was never told about.
For RTLA specifically, that means comparing how often each tier gets flagged against how many of those flags turned out to be real losses. A tier that gets flagged in proportion to its actual loss rate is unremarkable. A tier that gets flagged more than its loss rate justifies, or less, is the pattern that gets escalated, because that is what a proxy effect looks like in the data even when nothing that looks like a proxy was ever fed to the model.
This runs on a fixed schedule, not only when someone happens to look. Reports run quarterly against every tier, and any result that crosses a set threshold gets flagged automatically and routed for documented review, starting with a compliance read and moving up to a technical one from the modeling team, with an independent committee as the backstop if a disagreement doesn't resolve.
The admission rule catches the obvious proxies before they get near the model. The branch-level audit catches the ones that only exist as a pattern distributed across many features after the fact — and that second category deserves the larger share of the attention, because it is the one no feature list will show you.
The most practical anti-proxy tool we have is not statistical at all; it is a whitelist.
Populations swing for legitimate reasons, and to a model those movements present as anomalies. A seasonal town fills up with foreign workers and visitors at the same point every year. A wildfire or a hurricane brings in out-of-state contractors and relief crews who cash unfamiliar checks in volume. A state reissues routing or account numbers for a support program. Every one of those reads as coordination if it is read only in the data.
Figure 2. Representative categories. The specific patterns we maintain are client and geography dependent.
In each case the response is the same: verify the explanation, whitelist the pattern, and leave the population alone. The alternative is a model that imposes adverse treatment on a whole group of people in response to a shift with a perfectly ordinary cause, which is one of the principal ways a fair lending problem gets built by accident.
The mechanism deserves a direct description, because the decision to whitelist is manual and there is no automated rules engine standing behind it. We have built backend tools for detection rather than failing them. We monitor abnormalities in volume, so that when unfamiliar activity begins clustering in one geography or around one routing an analyst can look at it while the pattern is still new. From there a person confirms that the group is what it appears to be and documents it. That sequence is slower than letting a rule decide and I don’t mind that trade off since an automated whitelist can become a target for bad actors.
The project I am working on now is a tiered version of RTLA. The model was designed around what our largest partners can send, which can run to one hundred or more base features before any interactions are built on top of them, and many institutions cannot send data on that scale. A smaller bank or credit union may not be able to send negative data, may lack a full year of history, and may have limited customer-level detail. Under the original design that client either waits until it can instrument itself properly or receives nothing at all, and neither outcome is a good answer for an institution absorbing check losses.
So the question we are working on is how few features RTLA can run on while still being worth something on the first day it is deployed.
Figure 3. Tier structure in development. Feature counts are illustrative of design targets, not commitments.
I will be straightforward about the tradeoff, because a vendor who is not straightforward about it is understating the impact. The twenty-feature version performs materially worse than the full model, and that is not a modeling problem that tuning can solve, since twenty fields support only so much inference about where an account is heading. We could build a considerably stronger twenty-feature model, but the twenty features it would want are frequently the same ones a smaller institution cannot provide, which returns the exercise to where it started.
That makes the intermediate tiers the substantive part of the work. What we are really after is knowing which additions buy the most lift per unit of client effort, so that when an institution asks what to send us next, the answer is one specific and prioritized thing that moves its capture rate rather than an undifferentiated request for everything. There is no committed timeline on this, and I would rather describe the work honestly while it is in progress than represent it as finished.
Most of what is in this paper generalizes past our own model, so if you are evaluating anyone’s check loss model, including ours, these are the questions I would ask.
None of this displaces rigorous modeling. Class balance, hyperparameter tuning, validation discipline, and production monitoring all still must be right, and other papers in this series cover that ground in more detail.
What I have described here is the work that sits alongside it. A team of people who have watched fraud happen in person and who turn what they saw into features nobody would find in the data alone. Arule that every input be defensible by reference to a loss mechanism, which does more for fairness than any test we could run after the fact. It is also a preference for whitelisting legitimate populations rather than failing them, carried by a model design that scales down to meet an institution where it is rather than demanding that it arrive fully instrumented.
The thread running through all of it is that a loss model is a claim about people rather than about transactions. Building it that way is slower, less amenable to automation, and considerably harder to copy, and that is the part I would want a bank to be paying for.
About the author
Michael Serrette works in data science at VALID Systems, where he builds and deploys risk and fraud models for deposit and check portfolios, including Real-time Loss Alerts and modeling across multiple banking clients.
About this series
Data Science Perspectives is a set of practitioner-written papers from the VALID Systems modeling group on how our models are actually built, validated, and governed.
Note on specifics: the examples in this paper are illustrative. No client is identified, no portfolio results are disclosed, and no proprietary feature definitions are described. Institutions evaluating RTLA can request validated performance against their own book under a mutual non-disclosure agreement.