[Basics] Part 1. The card business and credit risk: where underwriting models begin
What a model should optimize for comes, in the end, from the business. Here's a walk through where a card issuer earns and where it loses, how credit loss breaks into parts, and how regulation makes its way inside the model. Consider it the domain groundwork for understanding an underwriting model.
Part 0 laid out seven ways finance data science differs from ordinary ML. This time I want to take a step back and look at where those differences come from. Namely, the domain.
That might sound a little dull. You came for model talk and suddenly it’s business talk. But this was one of the things I figured out fairly quickly after landing in this field: a model’s objective function comes from the business, not the code. If you don’t know where a card issuer earns and where it loses, then what your model should be optimizing for stays fuzzy too. So Part 1 is about the domain.
Where a card issuer earns, and where it loses
First, two kinds of companies sit inside a card payment. There’s the issuer, which issues the card and grants the customer a limit, and the acquirer, which signs up merchants and buys in the transactions. The one that eats the loss when a customer can’t pay is the issuer. So the credit-risk story is really the issuer’s story, and this series stands on the issuer’s side of the ledger.
An issuer’s revenue comes in roughly like this.
- Interest income: interest from revolving balances, installments, and cash advances. This is where credit risk works most directly, and in a portfolio heavy on revolving it can be the single largest share of revenue.
- Interchange (merchant fees): the issuer’s cut of the fee a merchant pays on every transaction. Since payment volume itself is the revenue source, this share looms large in markets where many customers only ever pay in full.
- Annual fees and other fees: things like annual membership fees, late fees, and foreign-currency fees.
On the other side, costs go out as funding cost, credit-loss cost (money that never comes back), operating expense, fraud loss, and the cost of rewards and points.
And here the underwriting data scientist’s objective function comes into view. We aren’t people who raise accuracy; we’re people who maximize good transaction volume while keeping losses under control. Decline too strictly and you lose the chance to earn; approve too loosely and you take credit losses. That balancing act is the essence of underwriting. When Part 0 said “you optimize expected profit and expected loss, not accuracy,” this is where it came from.
Splitting credit loss into three
The very way this loss gets handled differs from ordinary ML. In credit, we see expected loss as the product of three pieces.
EL = PD × LGD × EAD- PD (probability of default): the probability of default within a set window. This is the core of what scoring deals with.
- LGD (loss given default): the fraction you fail to recover once default happens.
- EAD (exposure at default): the exposure still outstanding at the moment of default.
We glanced at this formula in Part 0, but here I want to press on one more thing. The starting point for all of it is “what do you define default as.”
The target a scoring model tries to hit usually has this shape: “does the customer reach default within 12 months of applying?” Here the 12 months is the window over which you watch performance (the performance window), and “default” inside it is usually defined as 90+ days past due (the Basel convention). So “90 days past due within 12 months” often becomes a single bundled label. If “maximize volume while controlling losses” from earlier is the objective we optimize, this is the thing the model predicts. They live on different layers.
Days past due aren’t the only thing that settles a default. Even before 90 days is reached, if a debtor enters debt restructuring through a lawyer (legal intervention), normal recovery is effectively over, so it counts as default. The event “unlikely to pay” becomes a default regardless of the day count.
And whether you pull that threshold in to 60 days or leave it at 90, whether you set the window at 12 months or 24, the label changes wholesale, and when the label changes, so does the model. Delinquency, default, and write-off are all different stages. In ordinary ML the target is handed to you; in credit, defining the target is the first job.
The credit lifecycle and data science
A single customer’s credit lifecycle passes through roughly four stages.
- Acquisition: deciding who to market to. A response model attaches here.
- Underwriting: deciding whether to approve a new applicant, and what limit and rate to grant.
- Management: deciding whether to raise or lower an existing customer’s limit, whether to renew. A behavior score attaches here.
- Collections: deciding how to recover from a customer who has started to fall behind.
The model that attaches differs by stage, and so does the data you get to use. This series centers mostly on underwriting, and within that, on new-applicant underwriting. That’s where the hardest, and correspondingly most valuable, data problem lives.
New-applicant underwriting versus behavior evaluation
Both are the same “put a number on risk” job, but the two seats face quite different circumstances.
| New-applicant underwriting | Behavior evaluation | |
|---|---|---|
| Timing | At new application | While operating an existing customer |
| Data | Application info and external credit data | Own transactions, payments, delinquency history |
| Limit of observation | Rejected customers are invisible | Relatively rich |
| Use | Approval and limit | Limit changes, renewal, early warning |
Behavior evaluation looks at the rich transaction history of someone who is already our customer. New-applicant underwriting, by contrast, has to judge a first-time face, and to do it with nothing but the outcomes of the people we approved. It’s the seat where the selection bias from Part 0 bites hardest. Reject inference, which takes this problem head-on, gets its own treatment in Part 4; experimentation, its root-cause remedy, in Part 6.
History outside our own data: credit bureaus
Even when we first receive an applicant’s information, that person’s financial history isn’t a blank page. Credit bureaus supply the outside history. In Japan there’s CIC on the card-and-installment side, JICC on the consumer-finance side, and the Japanese Bankers Association’s personal credit information center on the banking side, with adverse and delinquency information partly shared across bureaus. In Korea, KCB or NICE plays a similar role.
Let me add one bit of practitioner instinct here. Too many inquiries in a short span is itself a risk signal. It can mean the person is reaching out to several places at once. And credit information has reporting lag and can be corrected after the fact, so you should always be suspicious of its data quality.
The things that come with cards specifically
Cards carry themes of their own. Revolving is a structure where interest accrues on the balance, so it’s a revenue source and, at the same time, a warning sign of over-indebtedness piling up. Catching the flow of revolving quietly accumulating on a customer with a thin transaction history is a classic feature-engineering task. Utilization (how much of the limit is being drawn down) is a powerful variable for reading behavior, and months on book (MOB, how many months have passed since the account was opened) becomes the time axis for the vintage analysis we’ll see later.
Regulation is part of the model
Finally, the thing you can’t leave out in this field is regulation. In other fields regulation is a constraint outside the model; in credit underwriting, regulation comes inside the model.
The legal skeleton of card underwriting in Japan is the Installment Sales Act (割賦販売法). When issuing a card and setting a limit, there is a duty to compute a “payment-capacity estimate” (支払可能見込額). You calculate it by subtracting living expenses and existing debt from annual income, and this is precisely the legal basis for underwriting. The number the model puts out isn’t a mere prediction; it becomes part of a calculation the law requires. And that estimated amount acts as a ceiling on the limit. Even if the model, looking only at risk and revenue, judges that a larger limit is better, it can’t grant beyond the legally defined payment-capacity estimate. A regulatory cap gets laid down as one more layer on top of the model’s output. Lending like cash advances is subject to the total-volume cap under the Money Lending Business Act (貸金業法) (a restriction against lending more than one-third of annual income), and the use of data itself is governed by the personal information protection law.
And the PD the model produces doesn’t end there. It flows into loan-loss provisions (expected credit loss under IFRS 9) and into capital calculations. It means a single probability from my model runs all the way through to the company’s financial statements. The weight of governance that Part 0 pointed at when it said “there’s a reason things are slow” comes from here.
Wrapping up
Only once you know the domain does the model talk start to mean something. The objective function comes from the business (maximizing volume while controlling losses), the target comes from the definition of default, the hardest data problem comes from the selection bias of new-applicant underwriting, and the output runs all the way through to provisions and capital calculations.
In Part 2 we’ll drop down another level and look at the statistical eye for reading this data. Before running any model, we’ll start with the distribution of credit data and with how to ask “is this difference real?”