Two very different data estates sit under this heading. On one side, community banks, credit unions, regional lenders, and wealth and trust firms: a core banking system you do not control, several bolt-on systems, and a small analytics team or none. On the other, payments and fintech: acquirers, issuers, processors, and the platforms built on top of them, where the volume is enormous, the smallest record is a single attempt to authorize a card, and most of the rules you have to model are written by someone else and change on their schedule. The failure modes are not the same, so the two are kept separate below.
Smaller institutions: community banks, credit unions, regional lenders, wealth and trust.
Relationship attrition early warning
In one line: Flags the household that is quietly walking out the door, weeks before the account closes.
Who uses it and when: the relationship officer, weeks before the account would otherwise close, on a short list of households showing the early signs instead of a closure notice after the fact. It changes one decision: whether to make the call this week.
What it does not do: it will not tell you why the household is leaving. It tells you which one, while there is still time to ask.
Usually already there.
It runs on transactions and balances that are already captured, because the core banking system cannot post a transaction without them. What is missing is agreement on who the customer is: the system is keyed on account, not person, households get inferred from a mailing address, and a joint account counts twice. The work is defining one household identity across checking, lending and wealth, which is reconciliation, not a new data programme.
The pain: “We find out we lost the relationship when the last account closes, and by then the mortgage is already gone.”
What it runs on
- One row per: two records, kept separate. One row per posted transaction (account, date, amount, type), and one row per account per day for balances.
- Described by: customer, household, account, product, branch, relationship officer, channel, date.
- Must agree across systems: customer and household above everything else. The same person has to be one person across checking, the loan system, and wealth. Product and branch have to be one list.
- History: you need history on product terms, officer assignment, and household membership. Who owned the relationship at the time is part of the answer.
One thing to watch: you can add up deposits across a month. You cannot add up balances across a month, only average them or take the last one. Getting this wrong is the single most common reason a banking dashboard shows numbers nobody believes.
Why it usually fails: the core system is keyed on account, not person. “Customer” is really “whoever is on line one of the account,” households get inferred from mailing address, and a joint account gets counted twice. Every per-household number is then wrong by an unknown amount, which is worse than being wrong by a known one.
Loan and onboarding file exception review
In one line: Tells the processor what is missing or inconsistent in a file before it reaches underwriting or an examiner.
Who uses it and when: the processor, before the file is sent up the chain, on a short list of what is missing or inconsistent instead of finding out from a bounce-back. It changes one decision: whether the file goes to underwriting today or waits on one more document.
What it does not do: it will not collect the missing document. It tells the processor what is missing while there is still time to get it.
Usually needs building.
It depends on knowing which documents were required on a given day, and that is not recorded anywhere; it lives in a Word template edited in place, so no history of what changed and when survives. Document type is not a field either, only whatever filename the uploader chose. Turning the checklist and the document type into data that keeps its own history is the project. The feature is what happens after it.
The pain: “Files bounce back and forth three times over one missing document, and every bounce costs us days.”
What it runs on
- One row per: one required document per application, whether or not it has arrived. The rows for documents that never showed up are the whole point. A record of what should exist is as valuable as a record of what does.
- Described by: applicant, product or loan type, originator and branch, document type, required date, received date, status, exception reason.
- Must agree across systems: applicant, product, and the document type list. The checklist the loan system uses has to be the same checklist compliance reviews against.
- History: you need history on the checklist itself. Which requirements applied on the day the application was taken is a different question from which apply today, and only the first one is defensible in a review.
Why it usually fails: the checklist lives in a Word template that gets edited in place, so there is no record of what was required when. Documents arrive as scans named by whoever uploaded them, with the document type living only in the filename.
Alert triage for fraud and AML review
In one line: Ranks the alert queue so analysts work the alerts most likely to be real, instead of top to bottom.
Who uses it and when: the analyst, at the start of the shift, on a queue ordered by which alerts are most likely to be real instead of the order they arrived in. It changes one decision: which alert gets worked first.
What it does not do: it will not clear the alert. It orders the queue; the analyst still makes the call on each one.
Usually needs work.
It depends on alerts that are already logged, one per rule per moment. The disposition, whether an alert was real, is free text in a notes field, so there is no clean label to learn from. Thresholds get tuned in place with no version history either. Nothing new has to be built. Disposition becomes a fixed set of values, and thresholds get dated, so this year’s alerts can be compared to last year’s.
The pain: “Our analysts clear a hundred alerts a day and ninety-eight of them were never going anywhere.”
What it runs on
- One row per: one alert generated. One rule, one account, one moment in time.
- Described by: customer, account, rule or scenario, analyst, date raised, date cleared, disposition, channel, product.
- Must agree across systems: customer, account, and analyst. The same customer identity used in the core system has to be the identity in the monitoring system.
- History: you need history on the rules. An alert raised under a threshold that has since been retuned is not comparable to one raised today unless the threshold in force at the time is recorded.
Why it usually fails: dispositions are recorded as free text in a notes field, so there is no clean label of “this one was real.” Without that label there is nothing to learn from, and no honest way to measure whether the ranking is working. Thresholds also get tuned in place with no version history, so last year’s alerts cannot be compared to this year’s.
Payments and fintech: acquirers, issuers, processors, and the platforms built on them.
Decline and retry review
In one line: Separates the declines that protected you from the declines that turned away a customer who was going to pay.
Who uses it and when: whoever owns the approval rate, at the regular review of decline reasons, on a split between the declines that protected the business and the ones that cost it a paying customer. It changes one decision: which decline rule gets a second look first.
What it does not do: it will not rewrite the decline rules. It shows which ones are worth reviewing; the rule change is still a human call.
Usually needs work.
It depends on the attempt-level record, which already exists somewhere, because the switch cannot process a card without logging it. Analysis just gets built on the settled file instead, because that is the one that reconciles to money, and declines never settle so they are excluded. Retries arrive as brand-new attempts with nothing linking them to the original. Nothing new has to be built. Analysis moves to the raw attempt log, and a retry key gets added to link the two.
The pain: “I can tell you our approval rate. I cannot tell you which of those declines cost us a customer who never came back.”
What it runs on
- One row per: one attempt to authorize a card. Approved, declined, reversed, timed out, all of them. This is by a wide margin the smallest record on this page, and summarizing it to a daily total per merchant before it is stored is the most common way the feature is lost before it starts.
- Described by: the bank that issued the card, the acquirer on the other side, merchant and outlet, card product, channel (in store, online, in app), how the card was presented, response code, currency, amount, and the timestamp to the second.
- Must agree across systems: merchant, issuer, and the response code list. Response codes are the thing everyone assumes is already standard. The same code can arrive carrying different meanings depending on which path the attempt took, and flattening them together teaches the model a category that does not exist.
- History: you need history on your own controls. Which rules and thresholds were in force at the moment of the attempt. A decline that happened under last quarter’s settings is not evidence about this quarter’s, and these settings get retuned constantly.
Why it usually fails: the analysis gets built on the settled file, because that is the file that reconciles to money and therefore the file everyone trusts. Declines never settle, so they are not in it, and the approval number ends up calculated against a denominator that quietly excludes every attempt that failed. The second cause is retries. An automatic retry arrives as a brand new attempt with nothing linking it to the original, so one customer trying four times looks like four customers, and the retry pattern that would have identified the false decline is unreadable.
Merchant and portfolio roll-up
In one line: Lets you see one merchant as one merchant across every outlet, franchise, and subsidiary it operates, instead of as several thousand unrelated ones.
Who uses it and when: whoever has to answer for a merchant total, when the question comes in, on one merchant figure instead of a request routed back to the account team. It changes one decision: whether that number gets trusted enough to act on.
What it does not do: it will not settle a disputed ownership record. It rolls up whatever ownership structure is on file; fixing a wrong one is still a separate step.
Usually needs work.
It depends on transactions at the outlet level, which are already captured; that part is not in question. Ownership above the outlet is also captured, just three times over: sales, risk and settlement each keep their own version of who owns whom, and none of the three is complete. Nothing new has to be built. One ownership hierarchy gets designated as the record, at whatever depth each branch actually has, and the other two get retired.
The pain: “Every total by merchant is wrong in a way nobody can quantify, so the report goes unused and we go back to asking the account team.”
What it runs on
- One row per: one cleared transaction at one outlet. The outlet is the floor. Everything above it is a roll-up, and the roll-up has to be derived from a recorded ownership structure, never typed onto the transaction.
- Described by: outlet, the merchant that operates it, the corporate parent above that, category, country, acquirer, channel, and date.
- Must agree across systems: the ownership structure above all, then category and currency. Sales, risk, and settlement each keep their own version of who owns whom, and each one is partly right. Currency is the quiet one: two amounts in two currencies cannot be added until somebody decides which rate on which date, and if that decision is made separately inside each report, the reports will disagree by small amounts forever and nobody will ever find the cause.
- History: you need history, and this is where it bites. Outlets get sold, franchises get bought back, chains merge. If you overwrite the parent when ownership changes, last year’s volume silently moves to this year’s owner and a year-over-year comparison shows growth that is only paperwork.
One thing to watch: a single payment has several dates and all of them are correct. When the card was presented, when the authorization came back, when it cleared, and when the money settled. They land in different windows and sometimes in different months. Decide which of those dates each report is built on, and put that on the report. Most arguments about a number that changed overnight are two people using two different dates and both being right.
Why it usually fails: the ownership structure is not the same depth everywhere. Some outlets hang directly off a corporate parent, some sit under a franchise group under a region under a parent, and some have nothing above them at all. Any roll-up written to assume a fixed number of levels will quietly drop the ones that are shallower or deeper than it expected. The totals still add up to something, which is exactly why nobody catches it.
Dispute and chargeback aging
In one line: Shows where every dispute actually sits and how long each stage really takes, so the ones about to run out of time get worked first.
Who uses it and when: the dispute team, each morning, on a short list of disputes closest to their deadline instead of a count of how many are open. It changes one decision: which case gets worked first today.
What it does not do: it will not file the response. It flags which deadline is closest; someone still has to act on it.
Usually needs work.
It depends on disputes that are already tracked, one row per dispute. The stage field is the problem: it gets overwritten as the dispute advances, so the record shows only where it is now, not how long it sat at each step. The amount at risk gets overwritten the same way as it is represented or conceded. Nothing new has to be built. Stage and amount both need a dated history instead of a single current value.
The pain: “I can tell you how many disputes are open. I cannot tell you which ones are about to age out on us.”
What it runs on
- One row per: one dispute, carried through its life and updated as it advances. Received, represented, escalated, decided, written off, each with the date it entered that stage and the amount in play at that stage. One row that gets updated in place, not a new row per stage.
- Described by: the original transaction, the bank that issued the card, the merchant and its acquirer, reason code, currency, amount, current stage, the deadline on that stage, and who it is waiting on.
- Must agree across systems: reason code, merchant, and the link back to the transaction being disputed. A dispute that cannot be tied to the transaction that caused it can be counted but never explained, and explaining it is the whole job.
- History: you need history on the rules, and they are not your rules. Reason codes and the time allowed at each stage change on the network’s schedule. A dispute filed under last year’s rules has to be measured against last year’s clock, so the rule set in force on the filing date has to be recorded alongside the dispute.
Why it usually fails: the stage field is overwritten as the dispute advances, so the record shows where it is now and nothing about how long it sat at each step on the way. Every stage-duration number then has to be reconstructed from case notes, which means it never gets reconstructed. The second cause is the amount, which moves as a dispute is partly represented or partly conceded. A report that reads the current amount and calls it the original one understates what was ever at risk.