Spade and the Payments Data Layer

You've glanced at a credit card statement and seen "DOORDASH*TAQ" where a restaurant name should be. Or "SQ *JOESCOFF" when you bought coffee from Joe's.

The descriptions have been this bad for decades.

The obvious explanation is negligence, that somebody along the chain could clean this up and hasn't bothered. But negligence isn't the constraint. The pipe that carries merchant data was designed in the 1960s, and it's only 40 bytes wide.

Spade built the side channel. Instead of fixing the pipe, they built a parallel data layer that matches each transaction to a verified merchant and returns structured data in under 40 milliseconds. They process up to 1.9 billion transactions on peak days. Stripe, FIS, and Increase have embedded their enrichment into issuing platforms that serve thousands of financial institutions.

This is a story about why payments data is structurally broken and what it takes to build the infrastructure that fixes it.

The 40-byte pipe

When you swipe a card, the terminal sends an authorization message to the card network. That message follows ISO 8583, a standard the financial industry adopted in the 1980s based on formats from the 1960s. It carries everything the issuer needs to approve or decline: card number, amount, currency, and a merchant descriptor.

The merchant descriptor lives in Data Element 43. DE43 gets about 40 characters total, with roughly 25 allocated to the merchant name.

Twenty-five characters. "TAQUERIA LA ESPERANZA #2" is already 24. A DoorDash order from that restaurant becomes "DOORDASH*TAQ" because every intermediary between the terminal and the issuer truncates what doesn't fit.

The problem compounds with intermediaries. A restaurant using Square gets a descriptor that starts with "SQ ", burning four characters before the merchant name begins. A DoorDash order prepends "DOORDASH", burning nine. By the time the descriptor reaches the issuer, the actual merchant name might be five truncated characters.

The 2023 revision of ISO 8583 introduced a longer sub-field for DE43, up to 255 characters according to implementer discussions. But adoption of spec updates across card networks, acquirers, processors, and terminals moves in years, not months. The 40-byte constraint is the reality most issuers still work with.

The four-digit world

The descriptor is garbled, and the category code that accompanies it is barely more helpful.

Every card-accepting merchant gets a four-digit MCC from its acquirer. There are roughly 900 codes for all of commerce. MCC 5812 is "Eating Places and Restaurants." That covers a Michelin-star tasting menu and a gas station hot dog counter.

Once assigned, the code sticks. A business that starts as a bookstore and pivots to selling electronics keeps its bookstore MCC unless someone manually requests a change. Amazon has been reported under MCC 5942 ("Book Stores") by some issuers. Technically accurate about Amazon's origin, useless about what you just bought.

Issuers use MCCs for fraud scoring, spend controls, and rewards attribution. A travel card that gives 3x points on "dining" needs to know whether MCC 5812 covers a sit-down restaurant or a food court inside an airport terminal. The code doesn't distinguish.

The same business can carry different MCCs on different networks. Visa, Mastercard, and American Express each maintain their own directories. A merchant with MCC 5411 on Visa ("Grocery Stores") might carry 5499 on Mastercard ("Miscellaneous Food Stores"). Fraud rules built on one network's classification break on another's.

So that's what an issuer gets when deciding whether to approve a charge: 25 garbled characters and a four-digit code that was assigned once and probably never updated.

The side channel

You can't widen the pipe from inside. Card networks would need every terminal, acquirer, processor, and issuer in the chain to adopt a wider format simultaneously. The authorization message has to traverse the network in 50 to 100 milliseconds. Adding fields adds latency to a path that's already tight.

Spade built the enrichment outside the authorization message. When an issuer receives a card swipe, it sends the raw descriptor to Spade's API in parallel. Spade matches the transaction to a merchant in its database and returns structured data before the authorization window closes.

Spade chose a parallel data channel over trying to improve the primary one. The issuer doesn't need the card network to carry better data. It calls a side channel and gets the merchant identity independently.

Latency determines whether this architecture is useful or decorative. If enrichment takes two seconds, it improves the customer's statement but can't inform the fraud decision. At P99 under 40 milliseconds (a figure Spade claims but no independent benchmark has verified), the enrichment arrives in time for the issuer's model to use merchant identity, location, and category as features.

Spade's card enrichment endpoint ingests ISO 8583 fields directly. The docs include field mappings for Marqeta, Galileo, Stripe, Lithic, Adyen, and Fiserv. The same DE43 string that's too garbled for a human to read is Spade's input.

Building the database

Spade's CEO, Oban MacTavish, has described enrichment as "a search problem, not a cleansing problem."

Legacy enrichment vendors take the garbled descriptor and try to classify it. Train a model on millions of noisy transaction strings, and the model learns that "DOORDASH*TAQ" is probably a restaurant. Accuracy improves with more training data, but the approach is bounded by the noise in its inputs. The model can guess a category, but it can't tell you which restaurant, at which address, with which phone number.

Spade starts from the other direction. Build a database of verified merchants first, then match each transaction to a record. The descriptor is a search query, not a training sample.

It's the difference between training a mail sorter to guess addresses from smudged envelopes and maintaining a directory of every address in the country. The smudged envelope still arrives, but instead of squinting at it, you match the legible fragments against known addresses.

Before licensing external data, Spade's team scraped and cataloged between 500,000 and 1 million merchant locations on their own. MacTavish has called the process "complicated, expensive, and time-consuming." They then licensed SafeGraph's Places dataset, covering over 80 million points of interest, to expand to what the company claims is 99.9% of US and Canadian card-accepting merchants.

Transaction data also flows back into the database. New patterns update merchant records, so coverage improves as volume grows. But the core asset is the verified merchant identities, not the transaction patterns. When a chain rebrands or a new coffee shop opens, the database updates from POI data, not from model retraining.

Spade's docs cite match rates of at least 95% with a proper implementation. Unmatched transactions still get cleaned merchant names, reorganized fields (phone numbers extracted from city fields, for example), and an industry classification. The system doesn't return empty-handed.

What the API returns

A matched transaction comes back with counterparty data, location data, and an industry classification.

The counterparty is the merchant. Each verified business gets a consistent ID across all its locations. Every Walmart shares one counterparty ID whether the transaction happened in Dallas or Detroit. The response includes legal name, trading name, logo, website, and phone number.

The location is the specific store. Each physical site gets its own location ID with full address, latitude, longitude, and a match score from 0 to 100. Online transactions return the merchant's headquarters.

The industry classification is a four-tier hierarchy. Where MCC gives a flat "5812" for all eating places, Spade returns a path: Food and Drink, then Restaurants, then Fast Food, then the specific sub-category. Each tier carries an ID in the format NNN-NNN-NNN-NNN, broadest to most specific. Recent additions include tiers for AI services, cannabis businesses, and mortgage lenders, categories that MCCs don't distinguish at all.

Spade also detects third parties. When you order through DoorDash, the authorization often shows DoorDash as the merchant. Spade separates the delivery service from the underlying restaurant, returning both: the counterparty (the restaurant) and the third party (DoorDash, typed as "delivery service"). Same for buy-now-pay-later providers, payment processors, and platforms.

This is what issuers can't extract from the authorization message alone. A fraud model that knows the merchant is a coffee shop in the cardholder's neighborhood scores differently than one that sees "SQ *JOESCOFF" and MCC 5812.

For issuers that want to act on the data during authorization, Spade offers action triggers. A card program can set rules at the merchant or category level: block transactions at cannabis dispensaries, restrict a card to grocery stores only, flag transactions above a threshold at specific merchants. The triggers evaluate during enrichment and return an authorization recommendation alongside the merchant data. Spade supports up to 300,000 active merchant triggers per scope, enough to cover a major issuer's full card portfolio.

The integration pattern

Spade's side-channel architecture has a natural distribution advantage. Platforms embed it once, and every downstream issuer gets enriched data without a direct integration.

Stripe embedded Spade into Stripe Issuing in February 2025 after testing "dozens of vendors," according to the partnership announcement. Issuing customers now access enriched merchant data through the Stripe API without making a separate call. The enrichment travels on the same authorization record.

FIS, one of the largest payment processors globally, embedded Spade across its debit platform. FIS debit issuing clients receive real-time merchant data on every card transaction. FIS processes debit transactions for thousands of financial institutions, which makes this a significant distribution channel.

Increase, a banking-as-a-service platform, added Spade enrichment records to card transactions in October 2026. The enrichment is optional, so transactions still clear when merchant data is unavailable. The integration exposes the full four-tier industry classification.

In all three cases, the platform absorbs the integration and downstream customers receive enriched data through an API they already use. A bank on FIS or a fintech on Stripe Issuing gets enriched merchant data without building a direct Spade integration. The side channel becomes invisible infrastructure.

This also explains Spade's distribution strategy. Moving from direct fintech clients (Mercury, Ramp, Sardine) to platform clients (Stripe, FIS, Increase) multiplies coverage without multiplying sales effort. Each platform partnership puts Spade's data in front of thousands of issuers.

What we can't verify

Spade reports P99 latency under 40 milliseconds, 99.9% coverage of US and Canadian merchants, over 99% accuracy, and up to 1.9 billion transactions processed on peak days. These are figures from press releases, investor announcements, and marketing pages. No independent benchmark compares Spade's accuracy against Plaid Enrich, MX, Ethoca, or other enrichment providers on the same transaction set.

The 1.9 billion is a peak figure, not average throughput. For context, Visa's network has a stated capacity of over 65,000 transactions per second. Spade handling 1.9 billion suggests multi-network, multi-client volume, though the figure could include batch reprocessing of historical transactions.

The "15% improvement in fraud models" that appears in partner marketing comes from a single blog post with no methodology disclosed.

The competitive landscape has an open question. Stripe's ML infrastructure already includes Financial Connections, which does ML-based transaction categorization for open banking data. At least one analyst has flagged Stripe's acquisition of Bridge as a potential move toward in-house enrichment that could reduce Spade's usage-based revenue from Stripe Issuing. Whether Stripe would build card-side enrichment when it can embed Spade is a business question, not an engineering one, but the dependency is worth noting.

Spade has raised $56.1 million across seed, Series A, and Series B rounds. With fewer than 50 employees, the team is small relative to the infrastructure it maintains. Current coverage is US and Canada only. Whether the merchant database approach scales to global coverage, where POI data is less standardized and merchant identity is harder to verify, is the next test.

The engineering insight survives the caveats. Building certainty on verified merchant identity, delivered through a side channel at authorization speed, is a different architectural bet than building sophistication on noisy descriptors. One approach tells the model which merchant, at which address, in which sub-category, while the other asks it to infer all of that from 25 truncated characters and a four-digit code.