What Training Data Powers Fraud Detection and Credit AI?

Why financial AI needs its own training data

A frontier language model can explain what a debt-to-income ratio is, draft a hardship letter, and summarize a 40-page credit policy. It cannot decide whether to lend someone $18,000, and it cannot tell you whether a card-not-present transaction at 2:47am is a compromised account or a customer on vacation. Those calls require a model that has seen what actually happened to comparable applicants and comparable transactions, at an institution that carried the loss when it got the answer wrong.

The demand side is not speculative. The FBI's Internet Crime Complaint Center logged 1,008,597 complaints in 2025, the first year the figure crossed one million, and $20.877 billion in reported losses, up 26% from 2024, with investment fraud accounting for $8.65 billion and business email compromise for another $3.05 billion. ^[6] Every dollar in that column is a detection failure a better-trained model might have caught.

Financial AI breaks into five applications, and the data that powers each one barely overlaps with the others:

• Fraud detection. Scores card, ACH, wire, and account-opening events in real time. Needs transaction sequences with confirmed fraud or not-fraud dispositions attached.
• Credit underwriting. Approves, declines, and prices consumer and small-business credit. Needs application-time feature snapshots paired with realized repayment or charge-off outcomes.
• AML and transaction monitoring. Surfaces money-laundering typologies and sanctions exposure. Needs KYC records, entity-resolution data, and alert dispositions, and this is where the law becomes a hard constraint rather than a cost.
• Collections, servicing, and support automation. Routes and scripts delinquency and hardship conversations. Needs call transcripts paired with the resolution that followed.
• Trading and robo-advisory. Predicts short-horizon price movement or generates suitable allocations. Needs tick-level market and order-book data, plus suitability records tied to real client profiles.

The data types that actually power financial AI

Practitioners rank financial datasets by row count. Buyers rank them by how much supervised signal survives the first hour of inspection. Here is what each major data type is actually good for.

• Transaction data. Card authorizations, ACH pulls, wires, P2P transfers, and open-banking aggregation feeds. Volume is enormous and value per row is low, until the stream carries merchant categorization, device and session context, and a downstream disposition.
• Credit bureau and alternative underwriting data. Tradelines, inquiries, and scores from the nationwide consumer reporting agencies, plus the alternative layer: rent and utility payment histories, cash-flow attributes derived from deposit accounts, telecom records, and payroll data. The alternative layer holds the differentiation, because bureau attributes are available to every competitor and are typically non-redistributable under the bureau contract.
• KYC and AML data. Identity documents, beneficial-ownership records, sanctions and PEP screening results, entity-resolution graphs, and monitoring-alert dispositions. High signal, and the most legally constrained category in the vertical.
• Loan performance data. Origination terms, application-time attributes, monthly payment and delinquency states, forbearance flags, and the terminal outcome: paid in full, charged off, settled, or sold. This is the closest thing the industry has to a gold-standard label.
• Collections and servicing call transcripts. Delinquency, hardship, dispute, and retention conversations paired with the outcome that followed. These train collections copilots and hardship-detection classifiers that nothing in a general corpus approaches.
• Market and order-book data. Consolidated tape, full-depth order books, and message-level feeds. Unlike the rest of the vertical, this data is broadly purchasable, so advantage comes from latency, reconstruction quality, and whether the vendor license permits model training rather than analytics only.

The gap between the first item and the fourth explains most of the pricing here. Sixty million raw transactions with no dispositions is a storage bill. Sixty million where 20,000 carry an adjudicated fraud verdict is a training set, and the 20,000 is the part that carries the price.

Why outcome-labeled data is the scarce, high-value asset

Financial institutions are not short of data. They are short of resolved data. A loan is not a training example on the day it funds; it becomes one after it runs to term, charges off, or settles. A transaction is not a fraud training example when it fires an alert; it becomes one after an investigator, a chargeback process, or a law-enforcement referral produces a verdict. Four properties make that resolved layer hard to accumulate.

• 1The label costs money and time to produce. Nobody can label a loan default by inspecting the application. Somebody had to lend the money, wait 24 to 60 months, and absorb the loss. A five-year book of seasoned outcomes represents five years of an institution's capital at risk, which is why it cannot be synthesized or scraped.
• 2You only observe outcomes for applicants you approved. This is the reject-inference problem, and it has no clean analogue in most other verticals. A lender's book is censored by its own past policy: every declined applicant is a missing row, and a model trained on the survivors inherits the old policy's blind spots. A book that retained the declines and their scored attributes is worth substantially more than one that did not.
• 3Fraud labels are rarer than fraud alerts, and both classes matter. Most alerts close without a definitive finding, so a dataset of alerts is really a dataset of one institution's threshold settings. Adjudicated outcomes are supervised signal, and the cleared cases are not filler: they define the negative class that keeps a fraud model from flagging every third travel purchase.
• 4The label is regime-dependent and decays. A consumer book originated in 2021 was labeled under stimulus transfers, payment pauses, and forbearance programs, and its default behavior does not transfer cleanly to 2026 underwriting. Fraud patterns rotate faster still. The interagency model-risk guidance the OCC, Federal Reserve, and FDIC issued in April 2026 makes the same point from the supervisor's side, and notably declines to bring generative and agentic AI models into its scope at all. ^[4]

The two defects that quietly kill financial datasets

Two structural defects turn nominally large datasets into unusable ones, and both are specific enough to finance that generalist buyers routinely miss them.

Target leakage through refreshed attributes. Most loan systems of record overwrite bureau attributes and internal scores as they refresh. If a borrower's tradeline data was pulled at application in March 2022 but the stored value reflects a January 2026 refresh, the row silently encodes the outcome, because a borrower who charged off in 2024 looks different at refresh than one who paid off. Models trained on that data post spectacular backtest results and fail in production. The fix is a decision-time snapshot, and whether the seller has one is the first question worth asking in a loan-data diligence call.

Model-generated labels masquerading as ground truth. Merchant categorization, income estimation, and cash-flow attributes increasingly come from the seller's own models rather than humans or source records. Training on those outputs compounds the original error and narrows the distribution. Ask which fields are observed, which are derived, and which are predicted, and price the third category near zero.

The US rulebook: GLBA, FCRA, ECOA, and the SAR wall

Financial data does not have one governing statute. It has a stack of them, and different layers of the same dataset fall under different regimes. A single consumer loan file can contain GLBA-protected nonpublic personal information, FCRA-governed consumer report data, ECOA-relevant decision records, and, if the customer was ever monitored for suspicious activity, information that may not be disclosed at all.

GLBA: the security and sharing floor

The Gramm-Leach-Bliley Act governs how financial institutions handle nonpublic personal information, through a Privacy Rule limiting disclosure to nonaffiliated third parties and a Safeguards Rule setting security standards. The FTC's Safeguards Rule, 16 C.F.R. Part 314, implements GLBA sections 501 and 505(b)(2) and requires a written information security program built on a documented risk assessment, access controls limiting data to authorized users, encryption of customer information in transit and at rest, and contractual obligations plus periodic assessment for every service provider that touches the data. ^[2]

Three consequences shape any licensable dataset. The privacy notice the institution gave its customers sets the outer boundary of permitted sharing, so a wind-down entity has to reconcile its notice language against the transfer it wants to make. The service-provider provisions follow the data to the buyer, making the buyer's security posture a diligence item for the seller. And dropping a name field does not remove data from scope, because the analysis turns on whether the information remains personally identifiable financial information.

FCRA: a closed list that does not include model training

The Fair Credit Reporting Act is more restrictive than most AI buyers expect, because it does not work as a general reasonableness standard. Section 1681b(a) states that a consumer reporting agency may furnish a consumer report only under the enumerated circumstances "and no other", a list covering credit transactions, employment purposes, insurance underwriting, account review, government benefits, court orders, and the consumer's own written instructions. ^[4] Training an AI model is not on that list.

So bureau-derived attributes almost never travel. Even where FCRA's text leaves ambiguity, lender contracts with the nationwide consumer reporting agencies routinely prohibit redistribution outright. The workable path is to exclude bureau fields and retain the internally generated layer: application answers, cash-flow behavior from the institution's own deposit relationship, servicing history, and outcomes. That layer is also the differentiated part, since every competitor can buy bureau data and nobody else can buy the institution's performance history.

ECOA and Regulation B: explainability is a legal requirement, not a best practice

The Equal Credit Opportunity Act requires a creditor taking adverse action to give the applicant a statement of specific reasons. Regulation B implements it, and the operative language is unusually blunt about what does not count.

That sentence predates machine learning in underwriting by decades, and it is why a model's explainability profile is a legal property rather than an engineering preference. The CFPB made the AI application explicit in Circular 2022-03, which held that creditors cannot justify noncompliance on the ground that their technology is too complex or opaque, and stated that a creditor's lack of understanding of its own methods is not a cognizable defense. ^[2]

The durable consequence for sellers: buyers building credit models need data that supports reason-code generation, meaning interpretable features with stable, documented definitions across the time span of the book. A dataset of 900 unlabeled engineered features is worth less to a lending buyer than 60 documented ones, because the second can be defended in an adverse-action notice and the first cannot.

The SAR wall: why AML data mostly cannot be licensed

AML is the use case where buyers most want labeled data and where the law most firmly refuses. Under the Bank Secrecy Act's implementing regulations, a Suspicious Activity Report and any information that would reveal its existence are confidential. The text is categorical: "No bank, and no director, officer, employee, or agent of any bank, shall disclose a SAR or any information that would reveal the existence of a SAR." An institution served with a subpoena for a SAR must decline to produce it, cite the regulation and 31 U.S.C. § 5318(g)(2)(A)(i), and notify FinCEN of both the request and its response. ^[4]

No indemnity solves that. It removes the single most valuable AML label, the confirmed suspicious-activity determination, from the licensable market entirely. What remains is the surrounding layer: KYC and identity-verification records, entity-resolution and beneficial-ownership graphs, sanctions-screening match and false-positive data, and typology documentation that does not reveal whether any specific filing exists. Buyers building transaction-monitoring models should expect to train largely on synthetic typologies and internally generated alert data, and sellers should treat any AML-adjacent field as excluded until counsel clears it.

The EU AI Act: credit scoring is high-risk, fraud detection is carved out

Anyone training on EU consumer credit data, or selling a credit model into the EU, lands inside the AI Act's high-risk regime. Annex III, point 5(b) covers "AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score," and then adds a carve-out that matters enormously for this vertical: "with the exception of AI systems used for the purpose of detecting financial fraud." ^[4]

The asymmetry is deliberate. A model that decides whether to extend credit carries the full high-risk obligation set. A model that decides whether a payment is fraudulent is not classified as high-risk on that basis, on the reasoning that fraud detection protects consumers rather than allocating access to them. Institutions running one risk engine that does both should expect to document the boundary, because classification follows the intended purpose rather than the codebase.

For high-risk credit systems, Article 10 turns training data into a compliance artifact. Providers must subject training, validation, and testing data sets to governance practices covering design choices, collection processes, preparation operations including annotation, labelling, cleaning, and aggregation, the assumptions about what the data measures, and an assessment of availability, quantity, and suitability. Those data sets must be relevant, sufficiently representative, and, to the best extent possible, free of errors and complete for the intended purpose, and must account for the geographical, contextual, behavioural, and functional setting where the system will operate. Article 10 also mandates examination for biases likely to affect fundamental rights or lead to discrimination. ^[2]

Article 10 converts documentation into an asset. A European lender's loan book sold with collection methodology, field definitions, geographic coverage, and a bias examination already written down is directly usable by a provider building toward a December 2027 conformity assessment. The same book sold as a CSV forces the buyer to reconstruct all of it, and that cost comes out of the price.

Data type, AI use case, and the regulation that governs it

Worked example: evaluating a wind-down lender's loan book

Consider a US consumer-lending fintech shutting down after failing to raise. Its data room advertises 2.4 million funded installment loans across seven years, 61 million categorized transaction records from linked deposit accounts, 118,000 fraud-flagged applications, and 340,000 collections and servicing call recordings. Here is how the evaluation runs, and why the headline number is not the number that matters.

• 1Season the book first. Only loans that reached full term, charged off, or settled carry a definitive outcome; loans originated in the last 18 months are unresolved. If roughly 1.55 million have terminated, that is the outer bound on credit-label supply, and the remaining 850,000 are inventory rather than training data.
• 2Check that the terminal status is structured. Of the 1.55 million terminated loans, how many carry a machine-readable status code plus a monthly delinquency history, rather than an outcome buried in servicing notes? Assume 1.31 million do. That is the working population.
• 3Isolate the positive class. At a 7.8% lifetime charge-off rate, roughly 102,000 loans are defaults. That count, not the 2.4 million, sets the effective ceiling on how well a default model can be fit, and it is the number a sophisticated buyer anchors on.
• 4Test for point-in-time integrity. Were application attributes snapshotted at decision or overwritten by later refreshes? This is where most books lose the majority of their value. Suppose 740,000 loans have a verified decision-time snapshot: that is the trainable underwriting subset, down 69% from the headline.
• 5Ask for the declines. Were scored-but-declined applications retained with their attributes? If yes, the buyer can address reject inference and the dataset is materially more valuable. If the lender purged declines on a retention schedule, disclose it up front, because a buyer finds it in week two of diligence and reprices.
• 6Adjudicate the fraud slice. Of 118,000 flagged applications, how many have a confirmed disposition? Assume 21,500 do, split roughly 6,900 confirmed fraud and 14,600 confirmed clean. That two-class set is small, hard to source anywhere else, and the most defensible line item in the package.
• 7Separate observed from derived transaction fields. Of the 61 million records, which fields are raw (amount, timestamp, counterparty, network-delivered MCC) and which came from the lender's own categorization or income-estimation models? Disclose the split rather than letting the buyer find it.
• 8Run the legal exclusions before any sample leaves the building. Strip bureau-sourced attributes, which cannot be redistributed. ^[4] Confirm the customer privacy notice permitted this transfer and that the buyer can meet Safeguards Rule service-provider obligations. ^[6] Exclude every AML-adjacent field until counsel clears it. ^[8] Tokenize names, SSNs, account and routing numbers, and device identifiers.

How financial training data gets priced

Financial datasets price against the same seven drivers that govern every vertical Dayda works in: volume, quality and annotation depth, domain scarcity, metadata richness, recency, licensing terms, and legal cleanliness. Four of them do most of the work here, and one behaves differently in finance than anywhere else.

• Annotation depth dominates. Here it means outcome resolution: what fraction of rows carry a terminal label, and whether that label is structured. The worked example is the whole argument, since label integrity moved the trainable population by a factor of three.
• Legal cleanliness is a gate, not a multiplier. A buyer with a compliance function will not touch a package containing bureau-derived attributes or AML-adjacent fields at any price. Clearing those exclusions in advance is the condition of getting a meeting.
• Recency behaves unusually. Fraud data decays in weeks because attack patterns rotate. Credit data decays in economic regimes rather than months, and an older book covering a full cycle including a downturn can beat a newer book covering only benign conditions, because downturn labels are exactly what stress models lack.
• Metadata richness means data dictionaries. Field definitions, collection methodology, and documented derivation lineage are the artifacts an EU buyer needs for Article 10 and a US buyer needs for reason-code defensibility. ^[4][6] Both convert documentation directly into price.

Licensing structure moves price the same way it does across every vertical. A non-exclusive license lets a wind-down entity sell the same book to a fraud vendor, a credit-model provider, and a research team without conflict, and it is usually the right default for a seller optimizing total proceeds. An exclusive license removes the asset from the market and commands a substantial premium over that baseline. What differs in finance is the shrinking window: retention schedules, servicer transfers, and the sale of the loan portfolio itself routinely separate a wind-down entity from its own performance history within months of the decision to shut down.

The loan tape and the fraud dispositions are the asset

Financial AI has no shortage of deployment. Fraud engines, underwriting models, monitoring systems, and collections copilots are all in production today. What is short is the resolved, outcome-labeled, point-in-time-correct data that separates a model that works from one that backtests well. That data exists almost exclusively inside institutions, it is bounded by GLBA, FCRA, ECOA, and the Bank Secrecy Act before it can move, and the EU AI Act now requires whoever trains on it to document how it was assembled. ^[2]

For a lender, neobank, payments company, or fintech winding down or pivoting, the practical question is narrow. Does the loan tape carry structured terminal outcomes, were the application attributes snapshotted at decision time, were the declines retained, and do the fraud flags come with adjudicated dispositions? Answer those four before going to market, exclude the fields that legally cannot travel, and a closed book that reads as a compliance liability turns into the scarcest input in one of the most competitive AI markets there is.