Does Paystack have its own fraud detection?

Yes — Paystack has built-in fraud screening that declines high-risk transactions before they reach you. Your application-level fraud detection is an additional layer for business-specific patterns that Paystack's general system may not catch: your specific customer base behavior, known bad actors from your own data, or industry-specific fraud patterns. The two layers are complementary, not alternatives.

What should I do when a transaction is flagged as high risk?

Route it to a human fraud analyst for review before taking action. Possible outcomes: allow (false positive), request additional verification from the customer (ID or OTP), or refund and blacklist. Never auto-block based on a risk score alone — false positive rates of even 1% mean blocking legitimate customers regularly. Build a review queue with clear SLAs so fraud decisions are made promptly.

Can an LLM help with fraud detection beyond rule-based scoring?

Yes — an LLM can analyze a cluster of flagged transactions and identify patterns your rule-based system missed. Feed it the flagged transaction data (not raw customer PII) and ask: "Are there common patterns across these flagged transactions?" It can surface non-obvious correlations. But keep the LLM in an analysis role — the actual block/allow decision should be made by a human fraud analyst, not the LLM.

By Bonaventure Ogeto|Updated July 22, 2026

Fraud Detection Signals with Machine Learning on Payment Data

Key fraud signals computable from Paystack data: 1) Velocity — more than N successful transactions from the same card or email in 1 hour. 2) BIN mismatch — card BIN (first 6 digits) country differs from customer's stated country (Paystack returns authorization.country_code). 3) Amount anomaly — large round amounts from first-time customers. 4) Email pattern — disposable email domains. 5) Time-of-day spike — unusual volume at 2-4am local time. These signals feed a risk score. Flag for human review at a threshold; do not auto-block. False positives cost real customers real money.

Computing Fraud Signals from Paystack Data

Paystack transaction data fields useful for fraud detection:

Signal	Paystack Field	What to Compute	Risk Indicator
Velocity	customer.email, paid_at	Count transactions from same email in last 1 hour	> 3 attempts in 1 hour = high risk
BIN mismatch	authorization.bin, authorization.country_code, customer metadata	Compare card-issuing country to customer country	Mismatch on first-time customer = medium risk
Amount anomaly	amount, customer history	Compare amount to customer's average transaction	> 5× average from first-time customer = medium risk
Round amount	amount	Is amount divisible by 10,000 (kobo)?	Large round amounts from new customers = low-medium risk
Email pattern	customer.email	Check domain against disposable email list	Disposable domain = medium risk
Card reuse	authorization.signature	Count distinct customers using same card signature	> 2 customers on same card = high risk

// Risk scorer — computes a score from Paystack transaction data
async function scoreTransaction(txn) {
  var signals = [];
  var score = 0;

  // Velocity: count same email in last hour
  var recentCount = await db.transactions.countByEmailInHour(txn.customer.email);
  if (recentCount > 3) { signals.push('high_velocity'); score += 40; }
  else if (recentCount > 1) { signals.push('moderate_velocity'); score += 15; }

  // BIN mismatch: card country vs customer country
  var cardCountry = txn.authorization?.country_code;
  var customerCountry = txn.metadata?.customer_country;
  if (cardCountry && customerCountry && cardCountry !== customerCountry) {
    signals.push('bin_country_mismatch'); score += 20;
  }

  // Card reuse across multiple customers
  var cardCustomers = await db.transactions.countCustomersByCardSignature(txn.authorization?.signature);
  if (cardCustomers > 2) { signals.push('card_shared_across_customers'); score += 50; }

  // Disposable email
  var disposableDomains = ['mailinator.com', 'guerrillamail.com', 'temp-mail.org'];
  if (disposableDomains.some(d => txn.customer.email.endsWith('@' + d))) {
    signals.push('disposable_email'); score += 25;
  }

  return { score, signals, action: score >= 60 ? 'review' : score >= 30 ? 'monitor' : 'allow' };
}

Learn More

See AI-assisted reconciliation for the broader AI in financial operations context.

Sign up for the McTaba newsletter

Key Takeaways

✓Fraud signals are inputs to a risk score — not triggers for automatic blocks.
✓Velocity, BIN mismatch, amount anomaly, email pattern, and time-of-day spike are the core signals from Paystack data.
✓Paystack returns authorization.country_code and authorization.bin — use these for BIN-country mismatch.
✓False positives in fraud detection block legitimate customers — tune thresholds conservatively.
✓All fraud flags should route to human review before action, not auto-block.

Frequently Asked Questions

Does Paystack have its own fraud detection?: Yes — Paystack has built-in fraud screening that declines high-risk transactions before they reach you. Your application-level fraud detection is an additional layer for business-specific patterns that Paystack's general system may not catch: your specific customer base behavior, known bad actors from your own data, or industry-specific fraud patterns. The two layers are complementary, not alternatives.
What should I do when a transaction is flagged as high risk?: Route it to a human fraud analyst for review before taking action. Possible outcomes: allow (false positive), request additional verification from the customer (ID or OTP), or refund and blacklist. Never auto-block based on a risk score alone — false positive rates of even 1% mean blocking legitimate customers regularly. Build a review queue with clear SLAs so fraud decisions are made promptly.
Can an LLM help with fraud detection beyond rule-based scoring?: Yes — an LLM can analyze a cluster of flagged transactions and identify patterns your rule-based system missed. Feed it the flagged transaction data (not raw customer PII) and ask: "Are there common patterns across these flagged transactions?" It can surface non-obvious correlations. But keep the LLM in an analysis role — the actual block/allow decision should be made by a human fraud analyst, not the LLM.

Learn Paystack Integration

KES 2,999

The definitive guide to building payment systems with Paystack — from your first transaction to production-grade payment infrastructure across Africa. 9 modules, 47 lessons. Free preview available.

Start Paystack Course

Not ready? Create Free Account

By Bonaventure Ogeto|Updated July 22, 2026

Fraud Detection Signals with Machine Learning on Payment Data

Computing Fraud Signals from Paystack Data

Paystack transaction data fields useful for fraud detection:

Signal	Paystack Field	What to Compute	Risk Indicator
Velocity	customer.email, paid_at	Count transactions from same email in last 1 hour	> 3 attempts in 1 hour = high risk
BIN mismatch	authorization.bin, authorization.country_code, customer metadata	Compare card-issuing country to customer country	Mismatch on first-time customer = medium risk
Amount anomaly	amount, customer history	Compare amount to customer's average transaction	> 5× average from first-time customer = medium risk
Round amount	amount	Is amount divisible by 10,000 (kobo)?	Large round amounts from new customers = low-medium risk
Email pattern	customer.email	Check domain against disposable email list	Disposable domain = medium risk
Card reuse	authorization.signature	Count distinct customers using same card signature	> 2 customers on same card = high risk

// Risk scorer — computes a score from Paystack transaction data
async function scoreTransaction(txn) {
  var signals = [];
  var score = 0;

  // Velocity: count same email in last hour
  var recentCount = await db.transactions.countByEmailInHour(txn.customer.email);
  if (recentCount > 3) { signals.push('high_velocity'); score += 40; }
  else if (recentCount > 1) { signals.push('moderate_velocity'); score += 15; }

  // BIN mismatch: card country vs customer country
  var cardCountry = txn.authorization?.country_code;
  var customerCountry = txn.metadata?.customer_country;
  if (cardCountry && customerCountry && cardCountry !== customerCountry) {
    signals.push('bin_country_mismatch'); score += 20;
  }

  // Card reuse across multiple customers
  var cardCustomers = await db.transactions.countCustomersByCardSignature(txn.authorization?.signature);
  if (cardCustomers > 2) { signals.push('card_shared_across_customers'); score += 50; }

  // Disposable email
  var disposableDomains = ['mailinator.com', 'guerrillamail.com', 'temp-mail.org'];
  if (disposableDomains.some(d => txn.customer.email.endsWith('@' + d))) {
    signals.push('disposable_email'); score += 25;
  }

  return { score, signals, action: score >= 60 ? 'review' : score >= 30 ? 'monitor' : 'allow' };
}

Learn More

See AI-assisted reconciliation for the broader AI in financial operations context.

Sign up for the McTaba newsletter

Key Takeaways

✓Fraud signals are inputs to a risk score — not triggers for automatic blocks.
✓Velocity, BIN mismatch, amount anomaly, email pattern, and time-of-day spike are the core signals from Paystack data.
✓Paystack returns authorization.country_code and authorization.bin — use these for BIN-country mismatch.
✓False positives in fraud detection block legitimate customers — tune thresholds conservatively.
✓All fraud flags should route to human review before action, not auto-block.

Frequently Asked Questions

Does Paystack have its own fraud detection?: Yes — Paystack has built-in fraud screening that declines high-risk transactions before they reach you. Your application-level fraud detection is an additional layer for business-specific patterns that Paystack's general system may not catch: your specific customer base behavior, known bad actors from your own data, or industry-specific fraud patterns. The two layers are complementary, not alternatives.
What should I do when a transaction is flagged as high risk?: Route it to a human fraud analyst for review before taking action. Possible outcomes: allow (false positive), request additional verification from the customer (ID or OTP), or refund and blacklist. Never auto-block based on a risk score alone — false positive rates of even 1% mean blocking legitimate customers regularly. Build a review queue with clear SLAs so fraud decisions are made promptly.
Can an LLM help with fraud detection beyond rule-based scoring?: Yes — an LLM can analyze a cluster of flagged transactions and identify patterns your rule-based system missed. Feed it the flagged transaction data (not raw customer PII) and ask: "Are there common patterns across these flagged transactions?" It can surface non-obvious correlations. But keep the LLM in an analysis role — the actual block/allow decision should be made by a human fraud analyst, not the LLM.

Learn Paystack Integration

KES 2,999

The definitive guide to building payment systems with Paystack — from your first transaction to production-grade payment infrastructure across Africa. 9 modules, 47 lessons. Free preview available.

Start Paystack Course

Not ready? Create Free Account