Turn account data you already have permission to see into rewards your customers actually notice.
Open-banking apps, money managers and account aggregators.
You can already see where your customers shop. Turning that into revenue means being an affiliate of every one of those merchants, which is the same fourteen-contract problem a bank has, plus a consent regime on top.
And consent is the hard part: the customer has agreed to let you read their accounts, not to be tracked across the web. Any reward mechanism has to respect the boundary they actually agreed to.
Email and phone are hashed with your salt. This is the same identity spine every other rail hangs off.
POST /v1/end-users
When a customer accepts an offer, you mint a link for them. The click is attributed to that customer from the moment it is made — no cookie, no cross-site tracking.
POST /v1/links
Conversions arrive joined to the customer who earned them, with the commission we were paid, so your reward maths starts from a real number rather than an estimate.
GET /v1/conversions
Attribution comes from a link the customer chose to tap, not from watching them. Nothing here depends on third-party cookies.
You see what the network actually paid, per conversion, with the raw postback attached — so what you promise a customer is backed by money that exists.
The bank-link table exists in the schema but no endpoint writes to it, so there is no account-linking API to call today. Spend detection from bank data and the consent management around it are subsystem #7 and are not shipped. Everything above works now on the link-and-conversion path; the bank rail specifically does not.
POST /v1/end-usersPOST /v1/linksGET /v1/conversions