Data Engineering10 July 202614 min read

Acquirer Analytics: Build the Data Stack That Wins in 2026

Most acquirers are flying blind on the metrics that matter most. Here is how to build the internal analytics stack that turns transaction data into competitive edge.

Acquirer AnalyticsPayment DataFintechData EngineeringBusiness Intelligence

Acquirer analytics is the internal data capability that allows a payment acquirer, sub-acquirer, or payment facilitator to monitor authorization performance, understand portfolio profitability, detect risk concentrations, and make pricing decisions from facts rather than instinct. Without it, you are running a high-volume, margin-sensitive business on dashboards you did not build, metrics you cannot trust, and settlement files you reconcile manually in a spreadsheet.

The market context makes this urgent. In 2024, global acquiring revenues were approximately $48 billion, with steady growth driven by SMB digitisation. Value-added services such as data analytics and business management software now contribute to an estimated 25% of an acquirer's profit margin per merchant. And yet, inside the operations of most growth-stage acquirers and payfacs, the analytics layer is an afterthought — a collection of vendor portals, exported CSVs, and a Looker dashboard someone built eighteen months ago that nobody maintains.

This post is for CTOs, heads of data, and founding teams at acquirers and payment facilitators who know their data infrastructure is behind where it needs to be — and want a clear framework for fixing it.

Why Do Most Acquirers Struggle With Internal Analytics?

The honest answer is that acquiring businesses are built to move fast. You close merchant relationships, integrate with card schemes, and optimise for transaction volume. Internal analytics is not the product — it is the infrastructure that supports the product. And infrastructure investments get deprioritised until something breaks.

Data is often siloed in different platforms across the organisation that do not talk to one another. At the same time, it takes significant funding to build a custom solution that will link all internal and third-party data. Once data is wrangled, it can still take time for even a highly skilled analytics team to interpret, communicate, and apply insights towards better business decisions.

A pattern we see repeatedly in our work with early-stage acquirers and payfacs: the authorisation rate data lives in one system, settlement data lives in another, chargeback data comes in via a third-party report, and interchange cost data sits in a monthly invoice that someone keys manually into a spreadsheet. No single source of truth. No shared definitions. Finance says your effective interchange rate is 1.62%. Operations says 1.71%. Neither team knows which one is right, and leadership is making pricing decisions on the gap.

Enterprise merchants process millions of transactions across multiple payment service providers, yet most struggle with a fundamental challenge — their payment analytics live in silos. The same is true on the acquiring side. The problem is architectural, not analytical.

Fewer than one in five (18%) business leaders across industries believe they are getting sufficient ROI from analytics. Nearly half (45%) say they lack the skills to interpret and apply analytics in business contexts, while 41% struggle with siloed analytics and competing results.

The fix is not hiring more analysts. The fix is building the data stack correctly from the start.

Fintech payments risk analyst reviewing real-time acquirer analytics authorization and chargeback dashboard


📺 Watch: Payment Processing Credit/Debit Cards (Authorization, Clearing and Settlement Basics)

Payment Processing Credit/Debit Cards (Authorization, Clearing and Settlement Basics)


What Does a Proper Acquirer Analytics Stack Actually Look Like?

An acquirer's internal analytics capability needs to answer five distinct classes of question — and each requires a different data source, a different grain of data, and a different refresh cadence.

1. Authorisation Performance What is your acceptance rate by merchant, MCC, issuer, geography, and card type? Where are you losing transactions that you should be winning? How does your routing logic affect approval rates, and what does a one-percentage-point improvement in auth rate mean in gross processing volume?

Merchant acquiring success now demands precision execution across onboarding excellence, dynamic pricing intelligence, and predictive portfolio management. Merchant acquirers now demand sophisticated onboarding automation, dynamic pricing intelligence, and predictive analytics to win and retain profitable merchant relationships.

Authorisation analytics is where most acquirers leave money on the table. A decline rate that looks acceptable in aggregate often masks catastrophic performance in a specific issuer corridor or card-not-present segment. You will not find it without transaction-level data modelled at the right grain.

2. Settlement and Funding Intelligence Are your settlement files reconciling cleanly against your ledger? Are funding delays building up in specific corridors? What is your net funding position at any given moment, and how does it move across business days?

We have seen a capital reconciliation engagement at a Series A payment business uncover a $25M discrepancy that had gone completely undetected. At market borrowing rates, that gap was costing the business over $6,000 per day. The discrepancy was not fraud — it was a systematic misclassification in how settlement batches were being attributed across two processing entities. It only became visible once the settlement data pipeline was rebuilt properly in dbt and reconciled against a single source of truth in BigQuery.

3. Portfolio Profitability Which merchant segments are generating margin, and which are consuming it? When you strip out interchange, scheme fees, processing costs, and chargeback exposure, what is your net revenue per merchant cohort?

Looking towards new areas for growth, acquirers should have insight into geographic variances and high-risk categories to better understand where to expand and where to take a more measured approach. It also helps businesses understand merchant category concentration to mitigate risk, identify fast- and slow-growing categories, and align sales efforts.

This requires joining at least four data sources: your transaction processor, your scheme billing statements, your chargeback management platform, and your internal merchant CRM or contract database. Almost no growth-stage acquirer has this pipeline built. The ones that do make fundamentally better pricing and portfolio decisions.

4. Interchange and Scheme Cost Analytics Interchange cost visibility is not optional for a business running on thin margins. If you are on interchange-plus pricing with merchants, your profitability depends on the spread between what you charge and what you pay — and that spread is not static. It shifts with card mix, transaction type, authentication method, and MCC. Without a granular interchange analytics layer, you are guessing at your own unit economics.

If you have not already read our deep-dive on this specific challenge, Interchange Fee Analytics: Stop Flying Blind on Card Costs covers the modelling approach in detail.

5. Risk and Exposure Monitoring Chargeback ratios by merchant and MCC, fraud rate trends by channel, reserve adequacy against anticipated exposure, and early-warning signals for merchants approaching scheme thresholds — this is the operational risk intelligence layer that keeps you out of scheme programmes and protects your balance sheet.

Appropriately applied tools using machine learning fraud detection and rules-based systems can determine and control fraud prevention. The best fraud systems can recognise when something is wrong in real time, assessing transaction pattern analysis, customer behaviour analytics, and merchant activity monitoring.

If you are building or scaling a card programme alongside your acquiring stack, the Card Programme Analytics post covers the issuing-side complement to this framework.

How Should You Structure the Data Pipeline?

The architecture question we get asked most often is: "should we build a custom data warehouse or use the vendor-provided dashboards?" The answer is almost always: build your own, and use the vendor dashboards as a sanity check.

Vendor portals — whether from your processor, your scheme, or your chargeback platform — are designed to serve the vendor's use case, not yours. They slice data the way that is convenient for them. They use definitions that protect their interests. And they almost never join cleanly to your internal data about merchant contracts, pricing tiers, or cost structures.

Here is the architecture pattern we deliver for acquirers:

Ingestion layer Raw data from your processor API, scheme billing files (Mastercard and Visa billing statements), chargeback platform exports, and internal CRM or merchant management system. Each source has its own schema, its own grain, and its own latency. The ingestion layer standardises all of this into a raw schema in BigQuery or a cloud data warehouse of equivalent capability.

Transformation layer (dbt) This is where the real work happens. Settlement files get reconciled to funding records. Interchange is classified by fee category and joined to transaction records. Chargeback events are attributed to the originating transaction and merchant. Merchant-level profitability is calculated from first principles — not from a vendor's pre-packaged report. Every metric has a single definition, documented in the model, tested automatically on every run.

A pattern we see in acquirers that have tried to build this without dbt: the same metric is being calculated differently in three separate SQL queries, maintained by two different analysts, producing numbers that diverge every time the scheme updates a fee table. Migrating calculations into dbt models eliminates this class of error and cuts ongoing maintenance time significantly.

Semantic layer The transformation layer produces clean, tested, documented data models. The semantic layer — whether built in Holistics BI, Looker, or a dedicated SQL semantic layer — defines the business metrics that sit on top of those models. Auth rate, net revenue per merchant, effective interchange rate, chargeback ratio — all defined once, available everywhere, consistent across every report and dashboard.

When one payment data interface defines "acceptance rate" differently than another, your optimisation decisions become guesswork. Unified analytics transform scattered, PSP-specific data into normalised, real-time insights across all providers and regions. Instead of opening five different payment analytics interfaces to understand performance, a unified analytics dashboard integrates data and applies standardised definitions across providers to create a single, harmonised view.

Reporting and alerting layer Operational dashboards for the risk team (chargeback ratio alerts, fraud rate spikes), financial dashboards for the CFO (settlement reconciliation, net revenue by cohort), and executive dashboards for the CEO and board (total processing volume, margin by segment, merchant attrition). Plus automated alerting: if a merchant's chargeback ratio crosses a threshold, the risk team knows in minutes, not at the end of the month.

If you want to explore how Fintel Analytics approaches this for acquiring and payments businesses, see how we help businesses like yours — we design and deliver exactly this kind of end-to-end data stack.

Data engineer building acquirer data pipeline connecting processor API scheme billing and BigQuery warehouse

What Are the Most Common Mistakes Acquirers Make With Their Analytics?

Mistake 1: Treating scheme billing statements as the source of truth Scheme billing files are complex, often contain errors, and use fee categories that do not map neatly to your internal cost accounting. We have seen acquirers accept scheme billing at face value for years, only to discover systematic overbilling when they finally built a reconciliation pipeline. Always validate scheme billing against your own transaction records.

Mistake 2: Building dashboards before building the data model The Looker or Metabase dashboard is not the analytics stack — it is the front end. Acquirers frequently invest in BI tooling before the underlying data is modelled correctly. The result: fast-moving, visually appealing dashboards built on unreliable data. Invest in the transformation and semantic layers first.

Mistake 3: Using a single auth rate metric Authorisation rate without segmentation is almost meaningless. A 94% overall auth rate might mask a 78% rate on card-not-present transactions in a specific issuer corridor that represents 40% of your volume. Build auth rate as a multi-dimensional metric from day one.

Mistake 4: Not modelling merchant-level profitability Gross processing volume is the metric acquirers love to report. Net revenue per merchant cohort is the metric that tells you whether your portfolio is healthy. The application of artificial intelligence and machine learning — not just for fraud prevention but also for dynamic pricing, personalised customer checkout experiences, and predictive merchant underwriting — is now a dominant trend in acquiring. None of that AI-driven sophistication is possible without a clean, granular profitability model underneath it.

Mistake 5: No monitoring in production Data pipelines break. Settlement files arrive late. API schemas change without notice. An acquirer running critical financial operations on an unmonitored pipeline is one schema change away from producing wrong numbers that nobody catches for three weeks. Build data quality tests into every dbt model, and monitor pipeline health with automated alerting.

What Metrics Should an Acquirer Be Monitoring Daily?

Based on our delivery experience with payments businesses, here is the core metric set every acquirer's operational dashboard should cover:

  • Gross Processing Volume (GPV) — by merchant, MCC, geography, and card type. Daily, with trailing 7-day and 28-day comparisons.
  • Authorisation rate — segmented by channel (card-present vs card-not-present), issuer, geography, and authentication method. Any segment below your benchmark should trigger an alert.
  • Effective interchange rate — net interchange cost as a percentage of GPV. Tracked at portfolio level and by merchant pricing tier.
  • Chargeback ratio — by merchant and MCC, against scheme thresholds. Any merchant approaching 0.9% (Visa) or 1.0% (Mastercard) should be flagged automatically.
  • Settlement reconciliation status — are today's expected settlements matching actual funding? Any unreconciled items should surface immediately.
  • Net revenue per merchant cohort — which segments are profitable after all costs? Tracked monthly with trend.
  • Merchant attrition rate — how many merchants churned in the trailing period, and what was their contribution to GPV? With real-time insights, acquirers can strengthen merchant relationships by taking proactive measures that cut attrition.

Weekly executive reporting built on this metric set — replacing manual report assembly — is the kind of operational change that eliminates 90 minutes of manual work per week and ensures leadership is always working from the same numbers.

Frequently Asked Questions

Q: What is acquirer analytics and why does it matter?

A: Acquirer analytics is the internal data and reporting capability that enables a payment acquirer or payment facilitator to monitor authorization performance, portfolio profitability, settlement accuracy, interchange costs, and risk exposure from a single source of truth. It matters because acquiring is a margin-sensitive, high-volume business where decisions made on incomplete or siloed data directly erode profitability and increase risk.

Q: What data sources does an acquirer analytics stack need to integrate?

A: At minimum: your transaction processor or switch (for authorization and transaction-level data), card scheme billing files (Visa and Mastercard statements for interchange and scheme fees), your chargeback management platform, and your internal merchant management or CRM system. Most growth-stage acquirers also add fraud platform data and internal general ledger data for full financial reconciliation.

Q: How long does it take to build a proper acquirer analytics data stack?

A: A focused engagement with clear scope typically delivers a working data warehouse, transformation layer (dbt), and core operational dashboards within eight to twelve weeks. The critical path is data access and schema documentation from your processor and scheme partners — delays there are the most common cause of timeline slippage.

Q: What is the difference between acquirer analytics and merchant portfolio analytics?

A: Merchant portfolio analytics focuses on the risk and performance profile of the merchants you have acquired — identifying concentration risk, attrition signals, and category performance. Acquirer analytics is broader: it includes your own cost structure (interchange, scheme fees, processing costs), authorization performance at the network level, settlement and funding accuracy, and your net profitability as a business. The two overlap but are not the same.

Q: Should an acquirer build analytics in-house or work with a specialist?

A: Most growth-stage acquirers do not have the internal data engineering capacity to design and deliver this stack from scratch while also running the core business. A specialist data engineering partner can deliver a production-grade stack in weeks rather than quarters — and critically, one that is built on open standards (BigQuery, dbt, SQL semantic layers) that your internal team can own and maintain going forward. The goal is always to transfer ownership, not to create dependency.

Building a serious internal analytics capability is one of the highest-leverage investments a growth-stage acquirer can make — because every profitability decision, every pricing call, and every risk conversation is only as good as the data underneath it. At Fintel Analytics, we have helped fintech and payments businesses build exactly this kind of stack, from initial data audit and source system integration through to production-grade dbt models, semantic layers, and operational dashboards that teams actually use. If your authorisation data, settlement files, and scheme billing statements currently live in separate systems with no common model tying them together, that is a solvable problem — and solving it pays for itself faster than almost any other infrastructure investment you can make.

New from Fintel Analytics

Fintel Insight — AI audit of your data stack

Connect your GitHub or warehouse and get a scored report across cost, quality, security, and code health in under 10 minutes, with actionable recommendations to fix what matters most. $99 flat, data never stored, GDPR compliant.

Get your data audit →

Work with Fintel Analytics

Ready to unlock the value in your data?

We work with businesses globally to design and deliver data solutions that drive real, measurable results — from strategy through to production.

Book a free data strategy consultation →