Skip to content

Privacy by design, enforced by the database.

Customer data is the most valuable thing a loyalty programme holds, and the most dangerous to get wrong. Custas is built so the safe way to handle it is the only way the system allows. That holds for your staff, for our staff and for our own code.

Request our DPA See sub-processors

EU hosting

Finland, with the data kept in that region

Isolation per client

Enforced in the database, cannot be disabled

Per-client keys

Identifiers never stored in plain text

Zero tracking

No analytics, pixels or AI services

You’re the controller. We’re your processor, and we take that role literally.

Your customers’ data belongs to you. We process it only on your instructions and only to run the service, under a Data Processing Agreement as Article 28 requires.

You (controller) Custas (processor)
Decide why you collect data and which identifiers to use Enforce your choice, with sensitive IDs off by default
Write the consent wording your members see Version every wording and record exactly which one was accepted
Answer your members’ access and erasure requests Produce the export and carry out the erasure in one click
Set how long data is kept Prune and redact automatically, every night
Publish your privacy notice Provide a template and the facts it needs
Report a breach to the authority (IMY) within 72 h Tell you without undue delay, with what you need to report

Six layers of protection, all of them in the product.

Data that stays in the EU

Databases, backups and the application run on Google Cloud in europe-north1 (Hamina, Finland). The platform’s email relay runs in Stockholm. Data at rest does not leave the region, and backups are kept for 7 days, so an erasure is gone from every copy within a week.

Walls between clients that can’t be taken down

Every client’s data is separated by row-level security in PostgreSQL. The application’s database user doesn’t own the tables, so it cannot turn that protection off, even if our own code had a bug. A request with no client context sees zero rows, never all rows. These rules are checked automatically before the system is allowed to start.

Identifiers encrypted with your own keys

Personal identity numbers, emails, phone numbers and card numbers are never stored in plain text. Lookups use a keyed HMAC-SHA256 index under a key unique to your organisation. Where you need a value back, for example to send an email, it’s sealed with AES-256-GCM. Personal identity numbers are not readable back by default.

  • Separate encryption key and index key per client
  • Revealing an identifier needs a dedicated permission and is audited
  • Keys never pass through the database, so they can’t end up in its logs

Data subject rights, built in

When a member asks what you hold about them (Art. 15) or asks to be forgotten (Art. 17), you don’t start a project. You open their profile.

  • Machine-readable export of a member’s data, for access and portability
  • Erasure in a single transaction, with a tombstone so they aren’t re-imported by accident
  • Sales records kept anonymised for 7 years, as the Swedish Bookkeeping Act (Bokföringslagen) requires
  • Duplicate members merged, so one person has one record

Retention that runs itself

Data minimisation isn’t a policy document. Nightly jobs redact message contents and prune history once its retention period ends, based on your plan, with legal floors where the law requires records to be kept.

  • Message content kept 90 to 365 days, depending on plan
  • Audit log kept 90 days to 7 years, depending on plan
  • No raw ID numbers in logs: personal data is redacted before anything is written

The right people see the right data, and every look is on record.

A loyalty programme is used by shop staff, marketers, integrators and support. Each gets exactly what their job needs.

  • Roles

    Owner, admin, operator and read-only viewer. Viewers can never reveal identifiers.

  • Two-factor sign-in

    TOTP authenticator apps with recovery codes for every portal user.

  • Scoped API keys

    A till key only gets what a till needs. A key can never grant itself more.

  • Audit log

    Changes, identifier reveals and exports, with who, when and from where.

  • Instant revocation

    Server-side sessions: remove a user and they’re out on their next click.

  • Separate test environment

    Try campaigns and integrations without touching real people’s data.

What we don’t do matters as much.

Plenty of “compliant” tools quietly send visitor data to analytics, font and ad networks. Custas doesn’t, in the portal, in the member app, or on this website.

  • No analytics or session recording in any of our apps
  • No third-party fonts or CDNs: everything is served from our own servers
  • No customer data sent to AI services. Our assistant, Plick, runs inside the platform
  • No open or click tracking by default: every email goes out with the provider’s tracking switched off, and Custas never reads opens or clicks. Custas sends through Amazon SES (see the subprocessors below); if you connect your own SendGrid, Mailgun or Postmark account instead, turning tracking on there is your choice to make
  • No selling or sharing of your members with anyone, ever
  • This website sets no cookies, so there’s no cookie banner to click away

National ID numbers, handled the way regulators expect.

The Swedish Data Protection Act only allows personal identity numbers where clearly justified. Custas supports them properly, keeps them off by default, and never stores them readable unless you deliberately need to, for example for Kivra receipts.

Turning them on asks you to record your justification, which is kept with the setting, so you have an answer ready if a regulator asks. Your company name, privacy notice and privacy contact are shown to members wherever they sign up, consent or unsubscribe.

Sweden

Personnummer & samordningsnummer

Finland

Henkilötunnus (HETU)

Norway

Fødselsnummer

Denmark

CPR-nummer

Who else touches the data, and where.

We give at least 30 days’ notice before adding or replacing a sub-processor, and you can object.

Provider Purpose Location
Google Cloud Hosting, database, backups, logs Finland (EU)
Amazon Web Services (SES) Platform email relay, for clients without their own provider Sweden (EU)
46elks Platform SMS relay, on plans that include it Sweden (EU)
Apple Wallet pass refresh signal. The payload is empty and the pass is fetched from Custas Global, EU-US DPF
Google Wallet The member’s loyalty card in Google Wallet Global, EU-US DPF
Browser push services Member-app notifications, end-to-end encrypted so the service can’t read them Chosen by the member’s browser

Want to use your own email or SMS provider instead? On Growth and Enterprise you can connect your own account, under your own agreement with that provider.

The paperwork your DPO will ask for.

We’ll send the full set as part of any evaluation. Most come as templates you can adapt to your own business.

Request the documents

  • Data Processing Agreement

    Art. 28, accepted by your owner in the portal and recorded

  • Sub-processor register

    With locations and transfer basis

  • DPIA template

    A head start on your own impact assessment

  • Privacy notice template

    For your members, in plain language

  • Record of processing

    Art. 30(2), processor record

  • Breach runbook

    So you can meet IMY’s 72-hour deadline

This page describes how the Custas platform is designed and operated. It isn’t legal advice. Whether a particular use of personal data is lawful depends on your purposes and your legal basis, which you decide as controller.

Give your customers a reason to come back.

See Custas with your own till, your own offers and your own data rules. A 30-minute call is enough to know whether it fits.

Book a demo See pricing