Card Programme Analytics: Build Intelligence Into Your Issuing Stack

Card programme analytics is the data intelligence layer that transforms raw card transaction and authorisation data into the metrics a fintech issuer actually needs to run its programme as a business. Done properly, it tells you why your authorisation rate moved, which cardholders are drifting off-top-of-wallet, what your real interchange yield looks like after scheme fees, and where fraud or declines are concentrated. Done poorly — or not at all — you are operating a financial product with a massive blind spot.

This post is written for product, finance, and data leaders at fintech issuers: neobanks, embedded finance platforms, expense management tools, and any company that has issued cards as part of its product. If your card programme is live and your analytics are either non-existent or limited to a bureau extract from your issuer processor, this post is for you.

Why Most Fintech Card Programmes Have Broken Analytics

The painful truth is that most early and mid-stage fintech issuers inherit their analytics from their processing platform. They get a reporting portal — usually a static dashboard or a CSV export — and they treat that as their analytics stack. It isn't.

Issuer processor portals are built to report on what happened at the network level: authorisations, settlements, declines, disputes. They are not built to answer business questions like: "Which cardholder segments are driving the highest interchange yield per active card?" or "What is the relationship between onboarding channel and spend activation rate at day 30?" or "Are our decline rates worse on weekend evenings, and if so, is that a rules problem or a processor timeout?"

A pattern we see repeatedly: a fintech has issued tens of thousands of cards, has a live product, and has no reliable data on what percentage of issued cards have ever made a transaction. The activation metric either doesn't exist, or it exists in three different definitions across the product team, the finance team, and the issuer processor's dashboard — and none of the three numbers match.

A recent survey found that 54% of financial institution leaders identified data silos as their biggest barrier to innovation — and removing silos was the number one data strategy priority. For card issuers, those silos are structural: authorisation data sits with the processor, KYC data sits with the identity provider, spending category data requires network-level enrichment, and the finance team is reconciling interchange from a monthly settlement file. None of it connects automatically. Building that connection is the job.

📺 Watch: Personalizing Credit Products with AI Driven Analytics | FinTech-Aviv Annual Summit 2022

What Card Programme Analytics Actually Needs to Measure

Before you build anything, you need to be clear on the metric hierarchy. Not all card programme metrics are equal. Here is the framework we use when scoping a card analytics build.

Tier 1: Programme Health Metrics — the numbers without which you cannot tell if the programme is working at all.

• Card activation rate: The percentage of issued cards that have made at least one transaction within a defined window (typically day 7, day 14, day 30). This is not the same as cards issued, not the same as cards shipped, and not the same as cards provisioned to a digital wallet. Each of those is a different population, and conflating them is one of the most common errors we encounter.
• Monthly Active Card Rate: Of all cards that have ever activated, what percentage transacted in the last 30 days? This is your real active base.
• Spend per Active Card (SPAC): Average monthly spend across the active population. This is the single most useful leading indicator of programme economics and investor interest.
• Top-of-Wallet Rate: The share of a cardholder's total spend that flows through your card. This is hard to measure directly without open banking enrichment data, but you can approximate it using spend frequency and category breadth.

Tier 2: Economics Metrics — the numbers that tell you whether the programme is profitable.

• Gross Interchange Revenue: Total interchange earned before scheme fees. This requires joining settlement files with BIN-level interchange schedules — not something your processor dashboard does for you.
• Net Interchange Yield: Gross interchange minus scheme fees, processor fees, and any programme-level costs. This is the actual margin line for a prepaid or debit programme.
• Cost per Active Card: Total programme costs divided by active card count. At Series A scale, this number should be declining quarter-on-quarter. If it isn't, something is wrong with your activation or engagement model.
• Interchange Mix by MCC: Which merchant category codes are driving your interchange yield? This matters enormously for product decisions — a travel card with poor MCC concentration in travel MCCs is a product problem visible only in the data.

Tier 3: Operational Metrics — the numbers that keep the programme running without surprises.

• Authorisation Rate by Failure Reason: Not just "what is my decline rate" but "why are cards declining, and is the distribution of failure reasons what I would expect?" A spike in soft declines (insufficient funds) tells a different story than a spike in hard declines (security flags or rules blocks).
• Dispute Rate by MCC and Merchant: Elevated dispute rates in specific categories are an early warning signal for programme risk.
• Time-to-First Transaction: The median time from card activation (or provisioning) to first spend. This is a product conversion metric, not just an operational one.

Successful card programmes track multiple metrics including activation rates — the percentage of issued cards actually used — top-of-wallet status, and customer retention. What that description doesn't capture is that tracking these metrics requires a data engineering layer that most early-stage issuers simply haven't built.

The Data Architecture Behind a Card Programme Analytics Stack

Here is where the real work lives. A card programme generates data from multiple systems that do not natively talk to each other:

1. Authorisation data — typically delivered via webhook or file feed from your issuer processor (Marqeta, Galileo, Thredd, GPS, etc.). This is high-volume, event-level data. Every authorisation attempt, every approval, every decline, every reversal.
2. Settlement and clearing data — delivered T+1 or T+2, often as flat files. This is where interchange amounts are confirmed. The authorisation amount and the settled amount are not always the same (think hotel holds, fuel pump pre-auths).
3. Cardholder data — from your core platform or CRM: onboarding date, KYC tier, product type, acquisition channel, customer segment.
4. Scheme and BIN data — the interchange schedule for your BIN, network rules, MCC mappings. This often needs to be maintained manually or sourced from a third party.
5. Disputes and chargebacks — often in a separate system from authorisation data, with its own data model.

Connecting these five sources into a single coherent analytical model is the core data engineering challenge. In our experience, the teams that try to do this in spreadsheets — joining settlement files with cardholder exports in Excel — are the ones who end up with a $25M-equivalent discrepancy that has been sitting undetected for months. The numbers only look reconciled until someone looks closely.

The architecture we build for card issuers typically follows this pattern:

• Ingestion layer: Webhook receivers and file parsers that land all event data into a raw BigQuery or AWS data warehouse schema, partitioned by event date. Nothing transformed, nothing aggregated — raw source truth.
• Transformation layer (dbt): A set of dbt models that build the staging, intermediate, and mart layers. Key models include a cards dimension, a transactions fact table, a cardholders dimension, and a pre-built programme_metrics mart with the Tier 1/2/3 metrics above calculated to a consistent definition.
• Semantic layer: Metric definitions locked in a SQL semantic layer — so when the product team, finance team, and CEO all look at "active cards", they are looking at the same number, calculated the same way, from the same source. We use Holistics BI for this in most of our card issuer builds, as its self-serve model and semantic layer implementation are well-suited to the cadence at which card programme teams need to explore data.
• Alerting: Automated threshold-based alerts on authorisation rate, dispute rate, and programme cost — so the operations team is not discovering a problem in a weekly review meeting.

If you are looking to understand how this fits into a wider payment stack intelligence layer, our post on PSP data analytics covers the processor-side data model in more depth.

If you want to explore how Fintel Analytics designs and delivers this kind of card programme analytics stack, explore our services — we work with fintech issuers from initial data audit through to production deployment.

The Authorisation Rate Problem Nobody Talks About Enough

Authorisation rate is the metric that gets cited most in card programme conversations, and it is also the metric that gets analysed least rigorously. Here is why that matters.

Your processor dashboard will tell you an aggregate authorisation rate: say, 94.2% for the month. What it will not automatically tell you is:

• Whether that rate is better or worse for specific MCCs
• Whether the decline rate spikes on specific days or times
• Whether declines are concentrated in a specific customer segment (e.g., users who onboarded via a particular channel, or users with a particular spend profile)
• Whether the failure reasons have shifted — for example, an increase in "velocity check" declines might indicate either a fraud rules problem or a product problem (spending limits set too conservatively)

A pattern we have seen repeatedly: a Series A neobank had an overall authorisation rate that looked healthy at 93%. When we built a breakdown by decline reason and time-of-day, we found that approximately 18% of weekend-evening decline volume was coming from a single failure reason: a rules engine timeout that was not being caught by the processor's own monitoring. The processor was reporting it as a legitimate decline. The neobank had no idea. That kind of granularity does not come from a dashboard — it comes from having the raw authorisation event data in a warehouse with a transformation model that surfaces it.

Transaction insights through automated reporting and analytics support data-driven financial decisions — but only if the analytics layer is actually built to surface the right questions, not just aggregate the obvious ones.

Interchange Optimisation: The Underused Revenue Lever

For most prepaid and debit card issuers, interchange is the primary or only revenue line on the card programme itself (separate from any premium or subscription model). Yet in our experience, fewer than half of early-stage issuers have a clear view of their interchange yield broken down by MCC category, transaction size band, or cardholder segment.

This matters because interchange is not flat. The rate you earn varies by:

• MCC: Some categories attract higher interchange than others. A cardholder spending at a grocery retailer earns you a different rate than the same cardholder spending at a petrol station or a travel merchant.
• Transaction size: Many interchange schedules have fixed-fee components that make small-ticket transactions margin-dilutive.
• Card type and product tier: If you issue both standard and premium tiers, the interchange schedules may differ.
• Scheme: Visa and Mastercard interchange schedules are not identical.

Building an interchange yield model — one that computes expected interchange per transaction based on MCC, scheme, and transaction size, then compares it to actual settled interchange — gives you three things: a revenue forecast that is actually grounded in your spending mix, an immediate signal if something in your settlement file is wrong, and a product intelligence layer that tells you which card use cases generate the most revenue per active card.

We built exactly this for a Series A embedded finance company that had issued cards as part of a B2B spend management product. The interchange yield model revealed that their highest-volume transaction category (fuel) was one of their lowest-margin categories. That single insight shifted the product team's thinking about which merchant partnership integrations to prioritise next.

The number of active payment cards worldwide has exceeded 40 billion, with ongoing growth across debit, prepaid, and virtual programmes. As the market matures, the issuers who build analytical capability around programme economics — not just transaction volume — will have a structural advantage in understanding and defending their margin.

Building the Card Programme Analytics Stack: A Practical Sequence

If you are starting from nothing — or from a processor export and some spreadsheets — here is the sequence that works in practice.

Step 1: Establish the raw data foundation (weeks 1–2) Get all your data sources landing in one place. Prioritise authorisation webhook data and settlement file ingestion first. Do not transform anything yet — just land it, partitioned correctly, with a clear schema. The biggest mistake at this stage is trying to build dashboards before the data model is stable.

Step 2: Build the canonical data model (weeks 2–4) Write dbt models for your core dimensions and facts: cards, cardholders, transactions, settlements. Define what "active" means — once, in a single dbt model, documented in the model description. This is the step that prevents the three-different-numbers problem.

Step 3: Build the Tier 1 metric mart (weeks 4–6) Activation rate. Monthly active card rate. Spend per active card. Gross interchange. These four metrics, calculated correctly and consistently, are the foundation. Build them before anything else.

Step 4: Add the operational monitoring layer (weeks 6–8) Authorisation rate by failure reason, time-of-day, and MCC. Dispute rate trending. Time-to-first-transaction. Connect this to an alerting system so the operations team is not discovering problems retrospectively.

Step 5: Build the economics and optimisation layer (weeks 8–12) Interchange yield model. Cost per active card. Cohort-level spend analysis. This is the layer that turns the analytics stack from operational monitoring into actual business intelligence.

The total timeline is 10–12 weeks for a well-scoped build with clean source data. The two things that extend timelines in practice: undocumented or unstable processor data schemas (common with mid-tier processors), and undefined business metric definitions (common at seed and Series A stage). Both are fixable — but fixing them takes time that is not in the technical build estimate.

If you are also managing cardholder identity and balance data alongside your card programme, the challenges around data normalisation compound quickly. Our post on digital wallet analytics covers the balance and transaction data model problems that often sit adjacent to the card issuing analytics stack.

Frequently Asked Questions

Q: What is card programme analytics?

A: Card programme analytics is the data intelligence layer that transforms raw authorisation, settlement, and cardholder data from a card issuing programme into business metrics — covering programme health (activation, active rate, spend per card), economics (interchange yield, cost per card), and operations (authorisation rate by failure reason, dispute rate trending). It requires connecting multiple data sources that do not natively integrate: processor data, settlement files, cardholder data, and scheme-level interchange schedules.

Q: Why is my card programme authorisation rate misleading?

A: An aggregate authorisation rate hides critical variation. A healthy headline rate (e.g. 94%) can mask concentrated decline spikes by time-of-day, MCC, customer segment, or failure reason. Some failure reasons — like rules engine timeouts — are silently misclassified as legitimate declines by processor dashboards. You need raw authorisation event data in a warehouse, broken down by failure reason and dimension, to diagnose the real problem.

Q: How do I measure interchange yield for my card programme?

A: Interchange yield requires building a model that maps each settled transaction to the applicable interchange rate for that MCC, transaction size, card type, and scheme — then comparing expected interchange to what was actually settled. This is typically built as a dbt mart that joins your settlement file with a maintained interchange rate schedule. The output tells you yield by spending category, which transaction sizes are margin-dilutive, and whether your settlement is reconciling correctly.

Q: What data sources does a card programme analytics stack need?

A: At minimum: authorisation event data (from your issuer processor via webhook or feed), settlement and clearing files (T+1 or T+2), cardholder dimension data (from your core platform or CRM), scheme interchange schedules, and dispute/chargeback data. Connecting these five sources in a single coherent data model in a cloud warehouse is the foundational data engineering challenge for any card issuer analytics build.

Q: When does a fintech card issuer need to build its own analytics stack?

A: The moment you have issued cards at any material scale — typically once you reach a few thousand issued cards — you need more than your processor's reporting portal. That portal is built to report on network-level events, not to answer your business questions. If you cannot reliably answer "what is my activation rate at day 30?" or "which MCC categories are diluting my interchange yield?" from a single consistent source, you need a dedicated analytics stack.

The card programme analytics problem is one of the most underinvested areas in early-stage fintech — not because founders don't care about the metrics, but because the data engineering work required to connect the sources is non-trivial and rarely makes it onto the roadmap until something breaks. At Fintel Analytics, we have helped fintech issuers build exactly this kind of programme intelligence layer — from raw authorisation data ingestion through to interchange yield models and cardholder cohort dashboards — and the ROI typically shows up in the first quarter, whether through recovered interchange, reduced operational overhead, or an authorisation rate problem that has been silently costing revenue for months. If your card programme is live and your analytics are still limited to a processor portal and a spreadsheet, that is a fixable problem.