Privacy Model

The K42 network is designed so that no party has access to another party's raw data. Transaction matching, reward calculation, and campaign delivery all operate across trust boundaries without requiring any participant to share sensitive information.

Design Principles

• Member identity never leaves the Publisher - the Platform and Retailer have no knowledge of who your members are
• Transaction matching uses one-way cryptographic hashes - raw card details and amounts are never transmitted between parties
• Financial amounts are only visible to the Publisher and Retailer - the Platform never sees how much was spent

What Each Party Sees

Data	Publisher	Platform	Retailer
Member identity	Yes	No	No
Member attributes	Yes	No	No
Card details (auth code, BIN, network)	Yes	No	No
Transaction amounts	Yes (optional)	No	Yes
Basket/payment data	No	No	Yes
Transaction identifiers (hashes)	Yes	Yes	Yes
Merchant ID	Yes	Yes	Yes
Statement Descriptor	Yes	Yes	No
Cashback amounts	Yes	Yes	Yes
Deal/campaign configuration	Creatives only	Full	No

Transaction Identifiers

Raw card payment fields are combined and passed through a one-way cryptographic hash to produce a transaction identifier. Both the Publisher and Retailer independently compute the same identifier from their respective data.

The Platform sees only the resulting opaque identifier - it cannot recover the original values. This allows transaction matching without any party sharing raw payment data with one another.

For implementation details on how identifiers are computed, see Transaction Ingestion.

Trust Boundaries

During normal operation, the Publisher sends only anonymized transaction identifiers, the merchant ID and statement descriptor (needed for routing), timestamps, and deal references (clip IDs, loyalty program IDs, Airdrop IDs) to the Platform. Raw card details, transaction amounts, member identity, and attributes are never sent.

The Retailer sends only transaction identifiers and computed outcomes (cashback amounts, qualifying purchase status) to the Platform. Raw basket data, payment card details, and customer information are never sent.

Support Investigations

During normal operation, raw transaction data never leaves the Publisher. However, when investigating why an outcome was or wasn't produced (e.g. a missing cashback or an unexpected reward), the publisher can open a support ticket and provide additional transaction details for a specific transaction.

The support flow works as follows:

1. The publisher opens a support ticket on the Platform, providing the raw transaction details for the transaction in question (card network, auth code, BIN, merchant ID)
2. The Platform uses these details to perform an audited query against the Retailer software, asking it to look up how that specific transaction was matched and processed on their side
3. The Retailer software returns detailed match information, allowing the investigation to determine whether the transaction was matched, what outcomes should have been produced, and why

This is an explicit, auditable action - a support ticket is created and logged, and the raw details are shared only for the specific transaction under investigation. This never happens in bulk or as part of normal processing.