Using Transaction Enrichment for Fraud Detection and Risk Scoring

Fraud detection in financial services has always been an arms race. As fraud schemes grow more sophisticated, the data feeding your detection systems needs to keep pace. Yet most fraud teams are still working with the same raw transaction strings that banks have provided for decades — cryptic merchant descriptors, inconsistent formatting, and missing context that forces analysts to investigate manually. Transaction enrichment changes this equation entirely.

Why Raw Transaction Data Makes Fraud Detection Harder

A typical raw bank transaction might look something like this:

POS PURCHASE - SQSP*INV 4829173 SAN FRANCISCO CA
CHECKCARD 0301 PP*JOHN DOE 402-935-7733 CA
DEBIT CARD PURCHASE - TST* CORNER CAFE 12943

These raw strings are nearly useless for automated fraud detection. There is no standardized merchant name, no category, no indication of whether this is a known chain or an unknown entity. Fraud models trained on this data spend most of their capacity just trying to parse what the transaction is, rather than evaluating whether it is suspicious. The result is higher false positive rates, slower investigations, and fraud that slips through because the signal was buried in noise.

The problem compounds at scale. A fraud team reviewing thousands of alerts per day cannot afford to manually look up every unfamiliar merchant descriptor. When your rules engine flags SQSP*INV 4829173 as suspicious simply because it cannot identify the merchant, you are wasting analyst time on what turns out to be a Squarespace invoice.

How Enriched Data Improves Fraud Models

Transaction enrichment transforms those cryptic strings into structured, actionable data. Instead of guessing what TST* CORNER CAFE 12943 refers to, your fraud system receives a complete picture: the verified merchant name, its category, whether it belongs to a recognized chain, its business type, and an MCC code. Each of these fields adds a dimension that fraud models can use to make better decisions.

Verified Merchant Names

When your system knows the actual merchant behind a transaction, it can cross-reference against known fraud vectors. A transaction at "Starbucks" carries different risk than one at an unidentifiable merchant. Verified names also enable velocity checks across the same merchant, something impossible when each transaction has a slightly different raw descriptor.

Category and Subcategory

Enriched categories let fraud models understand spending patterns contextually. A sudden spike in "Gambling" transactions is a very different signal than a spike in "Groceries." Categories also enable peer comparison — does this user's spending pattern in a given category deviate from their history or from their demographic cohort?

Chain Detection

The is_chain field is particularly valuable for fraud scoring. Transactions at recognized chain merchants carry inherently lower risk than those at unknown, independent businesses. This does not mean independent merchants are fraudulent, but when combined with other signals, an unknown merchant in a high-risk category with an unusual transaction amount should receive closer scrutiny.

Red Flags That Enrichment Can Surface

Enriched transaction data reveals patterns that are invisible in raw data. Here are the key red flags your fraud system can detect once transactions are enriched:

• Mismatched MCC codes: When the enriched category does not align with the reported MCC code, it may indicate a merchant misrepresenting its business type — a common tactic used to avoid higher processing fees or regulatory scrutiny.
• Unknown or unresolvable merchants: If the enrichment API cannot identify a merchant, that is itself a signal. Legitimate businesses almost always have an identifiable presence. A transaction that enrichment cannot resolve warrants additional review.
• High-risk category concentration: Enriched categories make it trivial to detect when an account suddenly starts transacting heavily in high-risk verticals such as gambling, cryptocurrency exchanges, or wire transfer services.
• Geographic inconsistencies: When enriched merchant location data does not match the cardholder's expected geography, especially combined with non-chain merchants, the risk score should increase.
• Unusual business type patterns: A consumer account making repeated purchases at wholesale or B2B merchants may indicate card testing or an account takeover.

Building a Risk Scoring System with Enriched Fields

With enriched data, you can build a risk scoring function that evaluates multiple dimensions of each transaction. The following example demonstrates a straightforward approach using the fields returned by the Easy Enrichment API.

function calculateRiskScore(enrichedTransaction) {
  let score = 0;

  // High-risk categories add to the base score
  const highRiskCategories = [
    'Gambling', 'Cryptocurrency', 'Wire Transfers',
    'Money Orders', 'Digital Wallets', 'Adult Entertainment'
  ];
  if (highRiskCategories.includes(enrichedTransaction.category)) {
    score += 30;
  }

  // Unknown merchants are inherently riskier
  if (!enrichedTransaction.merchant_name ||
      enrichedTransaction.confidence < 0.5) {
    score += 25;
  }

  // Non-chain merchants in high-risk categories
  if (!enrichedTransaction.is_chain &&
      highRiskCategories.includes(enrichedTransaction.category)) {
    score += 20;
  }

  // MCC code mismatch with enriched category
  const expectedMCC = getMCCForCategory(enrichedTransaction.category);
  if (expectedMCC &&
      enrichedTransaction.mcc_code !== expectedMCC) {
    score += 15;
  }

  // Business type anomalies for consumer accounts
  const b2bTypes = [
    'Wholesale', 'Industrial Supply',
    'Commercial Equipment', 'Business Services'
  ];
  if (b2bTypes.includes(enrichedTransaction.business_type)) {
    score += 10;
  }

  // Chain merchants with high confidence reduce risk
  if (enrichedTransaction.is_chain &&
      enrichedTransaction.confidence > 0.95) {
    score -= 15;
  }

  return Math.max(0, Math.min(100, score));
}

This scoring function is deliberately simple to illustrate the concept. In production, you would weight these factors based on historical fraud data, account tenure, transaction velocity, and the specific risk profile of your user base. The key insight is that each enriched field contributes an independent signal that raw transaction data simply cannot provide.

You can extend this further by tracking enrichment results over time. If a merchant that previously enriched as a "Coffee Shop" suddenly resolves as "Cryptocurrency Exchange," that change in classification is itself a powerful fraud signal.

Integration with Existing Fraud Systems

Rules Engines

Most fraud platforms rely on configurable rules. Enriched fields make these rules far more precise. Instead of writing rules against raw merchant strings with wildcard matching — which generates endless false positives — you can write rules against clean, standardized fields. A rule like "flag transactions over $500 at non-chain merchants in the Gambling category" is only possible with enriched data.

Machine Learning Models

ML-based fraud detection benefits enormously from enriched features. Raw merchant descriptors require complex NLP preprocessing that introduces noise and latency. Enriched fields like category, is_chain, and business_type are clean categorical features that models can use directly. Teams that switch from raw descriptors to enriched fields typically see a measurable improvement in model precision without any changes to model architecture.

Real-Time vs. Batch Processing

The Easy Enrichment API supports both real-time and batch enrichment workflows. For transaction monitoring, you can enrich each transaction at ingestion time and feed the result directly into your streaming fraud pipeline. For retrospective analysis and model training, batch enrichment lets you process historical transactions to build richer training datasets.

Compliance Benefits: KYC, AML, and Suspicious Activity Reporting

Beyond fraud detection, enriched transaction data strengthens your compliance posture across multiple regulatory requirements.

Know Your Customer (KYC): Enriched transaction histories paint a clearer picture of customer behavior. When onboarding or reviewing an account, enriched data shows exactly where a customer transacts, in which categories, and with what types of merchants. This makes it far easier to verify that stated account purposes match actual usage.

Anti-Money Laundering (AML): AML monitoring systems need to identify structuring, layering, and integration patterns. Enriched categories and merchant identification make it possible to trace funds through identifiable businesses rather than opaque transaction strings. When a Suspicious Activity Report (SAR) requires documenting the nature of suspicious transactions, enriched data provides the merchant names, categories, and business types that regulators expect to see.

Suspicious Activity Reporting: Filing SARs with enriched transaction details reduces the back-and-forth with regulators. Instead of submitting raw descriptors that require manual interpretation, you can provide structured merchant information, clean categories, and MCC codes that align with regulatory taxonomies. This speeds up investigations and demonstrates to examiners that your monitoring program is thorough.

For more on how Easy Enrichment handles data security and compliance, see our security overview.

Getting Started

Adding enrichment to your fraud pipeline is straightforward. The API accepts raw transaction descriptions and returns structured data in milliseconds. A single API call transforms an unreadable bank string into a complete merchant profile that your fraud systems can act on immediately.

// Enrich a transaction and evaluate risk
const response = await fetch('https://api.easyenrichment.com/enrich', {
  method: 'POST',
  headers: {
    'Authorization': 'Bearer YOUR_API_KEY',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    description: 'POS PURCHASE - SQSP*INV 4829173 SAN FRANCISCO CA',
    amount: 49.99
  })
});

const enriched = await response.json();
// {
//   "merchant_name": "Squarespace",
//   "category": "Software",
//   "subcategory": "Website Hosting",
//   "mcc_code": "5734",
//   "business_type": "Software Publisher",
//   "is_chain": true,
//   "confidence": 0.96
// }

const riskScore = calculateRiskScore(enriched);
if (riskScore > 50) {
  flagForReview(enriched);
}