1Layer vs Triple (formerly Zizy): merchant data enrichment compared

Triple, formerly Zizy, is a serious merchant data enrichment product and one we meet regularly in competitive evaluations. On the parts of the product a demo shows you, we are close: both of us resolve cryptic card descriptors into a clean merchant name, a category, and a 512×512 logo, and both of us do it well enough that a side-by-side screenshot will not decide anything for you.

So this comparison is about the parts a demo does not show: how the data holds up outside a couple of core markets, how the logo library is maintained after launch, what the commercial and contractual shape is, whether you need a data processing agreement at all, and what implementation actually feels like once the contract is signed.

At a glance

Start with what is genuinely equivalent

Triple returns 512×512 logos, the same resolution we do. That is worth stating plainly, because it is the single biggest quality gap between us and much of the rest of the market — several enrichment APIs still cap out around 192 pixels wide, which upscales badly the moment a logo appears anywhere larger than a list avatar. Against Triple, that argument is off the table.

The core proposition is similar too: descriptors in, clean identity out, delivered by API. If your evaluation is a one-week proof of concept on a sample of well-known domestic merchants, expect both products to look good. The differences below are the ones that show up in month six, not in week one.

Coverage: strong in DACH and the UK, thinner elsewhere

Triple's centre of gravity is Germany and the UK. In those markets the data is good, and if your portfolio is a German or UK retail bank whose cardholders spend mostly at home, that concentration is a real advantage — depth where your volume actually is beats breadth you never touch.

What we hear consistently is that quality thins out with distance from those core markets, with the US and Asia the weakest. That matters more than the headline suggests, because unmatched transactions are not distributed evenly across your portfolio — they cluster exactly where the reference data is thinnest. A cardholder's trip to the US or a month in Singapore produces the least readable descriptors on their statement and the highest chance of an unrecognised charge, which is the moment enrichment is supposed to earn its keep.

We run one geography-agnostic matching engine across every region, currency, and language, over a database of more than 10 million merchants. In practice the useful test is not our average match rate or theirs — it is your unmatched rate broken down by country. Run it on both and the difference either shows up in your data or it does not.

Quality and update cadence

Equal resolution does not mean an equal library. We hold over 150,000 logos and refresh them daily, and every asset is re-rendered onto a standard 512×512 canvas with a respected safe zone and a consistent crop — so a list of ten merchants reads as one designed interface rather than ten marks pasted from ten websites. Triple does not publish a library size or a refresh cadence, so ask for both in writing.

Cadence is the part teams underrate at selection time and notice constantly afterwards. Brands rebrand, merchants change acquirer and descriptor, new subscription services launch weekly, and challenger brands appear in your data long before they appear in anyone's reference set. A library refreshed daily closes that gap in a day. A library on a slower cycle leaves your newest and most-discussed merchants — the ones customers are most likely to query — looking like blanks.

Data protection: designed not to need a DPA

This one changes your procurement timeline more than anything else on the list. Our enrichment is designed to run on the non-personal attributes of a transaction — the raw acceptor string, MCC, amount, currency, and acquirer identifiers. No cardholder identity, no PAN, no account references. When no personal data leaves your side, there is nothing for a data processing agreement to govern.

Our understanding is that a Triple deployment typically does require a DPA. That is not a criticism of their security posture — it is a consequence of the integration shape. But it is a real cost: legal review, DPO sign-off, sub-processor disclosure, a transfer impact assessment if data leaves the EEA, and an entry on your record of processing activities that has to be maintained for as long as the contract runs. At a regulated institution that is rarely a two-week detour.

The practical effect is that a 1Layer integration can often start while a comparable one is still queued behind privacy review. Confirm the analysis with your own DPO against your specific integration — we will happily walk them through exactly which fields we receive.

Commercials: per-transaction price, setup fees, and contract length

Three things compound here, and they are easy to miss when you compare a single unit rate.

• Per-transaction price — Triple sits at the premium end of the market on unit cost, which is fine at pilot volume and material once every transaction on the portfolio is being enriched.
• Setup fee — paid before you have proven the match rate on your own production data.
• Contract length — reports from evaluations point to a preference for longer lock-in, which fixes a rate for years in a category where coverage and pricing are both still moving.

Our model is the inverse: no setup fee, no minimum commitment, published volume-based pricing you can model in our calculator before you contact anyone. We would rather earn renewal on match rate than on notice periods — a vendor that needs a long contract to keep you is telling you something about the alternative.

Implementation and support

The recurring theme in what we hear from teams who have evaluated or used Triple is responsiveness: support that runs through standard channels, and less flexibility than expected when an integration needs something that is not already on the roadmap. We pass that on as second-hand and self-selecting — people who talk to us are, by definition, people who went looking. Ask for references and judge for yourself.

What we can state about our own side is specific. Every implementation gets a named product contact and a named engineer for the duration, in a shared channel with your team. Not a ticket queue, not a rotating success manager — the people who build the thing, answering the actual question, while you are integrating.

That is a deliberate choice about where enrichment projects actually stall. They rarely stall on the API contract. They stall on a category that needs to map to your internal taxonomy, on a descriptor family unique to your acquirer, on a sub-brand your product team wants split out, on a rendering edge case in your app. Those are all one conversation with the right person, and several weeks through a queue.

How to run the evaluation

1. Use one sample file across both vendors — a full month of real descriptors including the international tail, not a curated list of household names.
2. Break unmatched rows down by country. This is where a DACH/UK-weighted dataset and a geography-agnostic one diverge visibly.
3. Score logo coverage separately from name match. Both return 512×512, so the question is what share of your transactions get an asset at all.
4. Ask both vendors, in writing, for library size and refresh cadence.
5. Price the full contract term including setup fee, unit rate, and minimum — then divide by the transactions you will realistically enrich in year one.
6. Establish whether the integration requires a DPA before you scope the project, not after legal review starts.
7. Ask who specifically you will be talking to during implementation, and whether they are named in the contract.

Two products that demo identically can still differ by a quarter of your international transactions and six weeks of privacy review.

The short version

Triple is a credible product with genuine strength in Germany and the UK, and at 512×512 their logo assets are the equal of ours. If your volume is concentrated in DACH or the UK and a premium unit rate, a setup fee, a longer contract, and a DPA workstream are all acceptable, they will serve you well.

We are built for the portfolio that does not sit neatly in two countries, for teams who want daily-refreshed data rather than an unspecified cycle, for procurement that would rather not open a privacy review to clean up a statement, and for implementations where you want a named engineer instead of a queue. Run both on the same file, look at the unmatched tail by country, and let that decide it.