# Real-Time Card Data vs. Bank Feeds

Bank feeds show you what happened yesterday. Card network data shows you what's happening now. Here's why the difference matters for your platform.

## How Bank Feeds Work

### Aggregated from bank accounts, delivered after settlement

Open banking providers aggregate transaction data by connecting to bank accounts — either through bank APIs (where available) or through screen scraping. The data arrives after the bank has processed the transaction, typically 24–48 hours after the actual spend.

This approach was designed for account verification and balance checks. It works well for those use cases. For real-time card transaction monitoring, the structural limitations become apparent: latency is controlled by the bank, merchant descriptions are raw and inconsistent, connections are fragile (breaking on password changes, MFA updates, and bank API shifts), and there's no card-level granularity on corporate accounts.

## How Card Network Data Works

### Direct from card networks, delivered at authorization

Astrada connects directly to card networks. When an enrolled card is used, transaction data flows from the network to your platform at the moment of authorization — before the bank has even processed the transaction.

The data arrives structured and normalized: merchant name, MCC, terminal ID, acquirer ID, geolocation, transaction and billing currencies. The connection is persistent — once a card is enrolled, it stays enrolled. No re-authentication, no connection maintenance, no breakage.

## The Infrastructure Gap

### Bank feed pipeline vs. Astrada pipeline

|  | Bank Feed Pipeline | Astrada Pipeline |
| --- | --- | --- |
| Data arrives | N+1 to N+3 days after settlement | At authorization — seconds |
| File format | Varies per provider: proprietary specs, custom CSVs, inconsistent field structures | Single normalized API |
| Connection model | Per-bank SFTP server, encryption keys, credential-dependent | Direct card network connectivity — no bank dependency |
| Merchant data | Raw descriptor string (e.g. "AMZN MKTP US 1234") | Structured: merchant name, MCC, terminal ID, location |
| Multi-currency | Single settled amount — FX rate reverse-engineered | Transaction currency, billing currency, and conversion rate as separate fields |
| PCI burden | Your team manages SFTP servers, encryption keys, and file parsing per provider | Astrada handles PCI compliance — Level 1 certified |
| Coverage | Bank-specific — breaks when banks change processors | Visa and Mastercard — any issuer, US, Canada, UK, and Europe — expanding |
| AI readiness | Batch data requires buffering, deduplication, and format normalization | Structured real-time data feeds directly into agent workflows |

## What This Means

### Three scenarios where the difference matters

#### AI categorization

Your categorization agents need structured merchant data — not raw bank descriptions that vary by institution. Network-sourced MCC codes and normalized merchant names are consistent and machine-readable.

#### Real-time dashboards

A dashboard that updates 24–48 hours after transactions isn't real-time — it's a report. Card network data arrives at authorization, making your real-time promise actually real-time.

#### Expense reconciliation

Automated reconciliation is dramatically more accurate with 10+ structured fields than with raw bank descriptions. More matching dimensions, fewer false matches, fewer exceptions.

## Already Using Bank Feeds?

### "But we already use bank feeds"

That's fine — many platforms do, and many of our customers use both. Bank feeds are well-suited for account verification, balance checks, and transaction history. Astrada adds a layer that bank feeds structurally can't provide: real-time card transaction data with structured fields, delivered at the moment of authorization.

They're complementary, not either/or. Keep your bank feed provider for what it does well. Add Astrada for real-time card data.