Trust

We never ask for your operator backoffice password.

This page is the long version — encryption, audit log, admin access, and the compliance path we are on.

Last updated: 2026-05-19

Transparency note. This page describes the controls BetLink currently uses or is building toward. Material changes will be reflected here as the control set evolves.

Three things affiliates worry about, and what we do about them.

Honest framing first. Detail underneath.

A data breach exposes my deal terms and payout history.

Sensitive credential and payout fields are designed to be envelope-encrypted under AWS KMS Frankfurt with per-record data keys. If a snapshot leaks without the relevant keys, the data should not be readable; any notification decision still depends on the facts and applicable law.

An aggregator stores my operator backoffice password and gets compromised.

We do not ask for that password. We integrate via postback URLs and read-only API keys where possible, so password-compromise scenarios are intentionally outside the BetLink credential model.

A hostile attacker drains the payout fund or rewrites my wallet address.

Payout-address changes are gated by step-up MFA plus a twenty-four-hour cooldown. Every change is intended to be visible in your audit log. We do not reverse a fund movement on your behalf without a written request that can be verified out of band.

How encryption actually works here.

Plain-English summary; the deep technical brief is tracked in the compliance evidence package.

Sensitive credential and payout fields — operator API keys, postback HMAC secrets, payment-rail tokens, KYC index — are designed to be wrapped under a hybrid envelope scheme. The intended key root is AWS KMS in the Frankfurt region (eu-central-1).
Each individual record carries its own data-encryption-key (DEK). The DEK is generated at write time, used once, and discarded. The encrypted DEK lives next to the ciphertext; the KEK never leaves KMS.
EncryptionContext (AAD) on every wrap includes the workspace ID, the credential ID, and the purpose tag. A DEK wrapped for one tenant cannot be unwrapped against another tenant's context. This is enforced cryptographically, not by application code.
KEK rotation is automatic on a one-year schedule. Per-record DEKs are never rotated — each record carries a fresh key from day one, so rotation is a non-event.

Supabase Vault is used for our own infrastructure secrets only. Customer data does not pass through it, because the Vault master key is held by Supabase staff. The hybrid envelope keeps the master root on our side of the trust boundary.

A real-time audit log you can actually read.

Every decryption, every credential change, every admin touch — written to your view, hashable, and exportable.

Every sensitive operation writes a row into a per-workspace audit_events table — credential added, credential decrypted for postback dispatch, payout address changed, MFA challenge issued, admin investigated.
Rows are HMAC-chained: each row carries a MAC of the previous row. If anything is rewritten retroactively, the chain breaks on next verification.
Once per hour, the chain head is designed to be signed and anchored to immutable EU object storage. The signed root means retroactive changes should leave verification evidence.
IP addresses in the log are pseudonymised through a per-tenant HMAC. When you close your account, we shred the tenant key. The chain stays valid for verification; the IPs become un-correlatable. This is what makes the log GDPR Article 17 compatible despite being immutable.

You can view your audit log live at /settings/audit and export it as signed JSON. The goal is to make credential and admin-access events visible to the affiliate instead of hiding them in internal logs.

Honest admin access. Two lenses, no third one.

Most platforms quietly run with full impersonation and call it 'support'. Here is exactly what BetLink staff can do and what gets logged.

Lens A — investigate (read-only)

A BetLink staff member can open a silent, read-only view of your workspace if a fraud investigation, KYC escalation, or anti-money-laundering case requires it. Reads are silent at the moment they happen — this is required by AML 'tipping-off' rules. After ninety days, the session is revealed in your audit log unless it remains tied to an open suspicious-activity report. Sessions are capped at thirty minutes, require step-up MFA on the operator side, and are bound to an IP allow-list.

Lens B — support (read-write, consented)

A full read-write support session only happens with your explicit consent through a one-click button in your workspace. While it is active, a persistent banner is shown to both you and the operator, and both sides receive an email at start and end. Sessions are capped at one hour and produce a per-action audit trail tied to a GitHub Enterprise SSO identity, not a shared admin account.

The dual-lens pattern is closest in spirit to the engineering-blog write-up Pigment published in April 2026; it is intentionally stricter than the typical SaaS 'support shadow login'.

What we never ask for, and what some peers do.

Compared against publicly documented behaviour. Aggregators are listed for transparency only — names are withheld until counsel clears the comparison page.

Operator backoffice passwords. We use postback URLs and read-only API keys. Some peers — including ones that publish help articles such as 'Connecting an Affiliate Program (via Login Credentials)' and tools that accept bulk CSV credential uploads — do ask. We do not.
Two-factor codes, recovery codes, or device-binding seeds for your operator accounts.
Wallet seed phrases or full payment card numbers. Payouts run through partners with the appropriate licences; we hold a tokenised reference, never the underlying number.
Government ID for affiliates who do not opt into KYC. KYC is gated to tier-promotion and to payout thresholds that legally trigger it.

If any of this changes — if a future BetLink feature ever genuinely needs an operator-side credential — we will publish the rationale here and in the changelog before it ships.

Authentication standards.

What we require, what we encourage, and what we refuse.

Mandatory MFA on every paid workspace. Step-up re-authentication on payout-address changes, key adds, and admin-session consent.
TOTP supported today. WebAuthn / passkey support is in upstream beta; we will flip the default to passkey-preferred when the auth provider promotes it to general availability.
SMS as a second factor is a hard no. SIM-swap attacks are a documented, recurring vector in this industry, and we will not advertise SMS as security.
Enterprise SAML and SCIM through WorkOS arrive in Q3 2026.

Compliance targets, on the record.

Published targets for the controls and reviews we are working toward.

August 2026
Target: Drata kickoff, parallel SOC 2 Type 1 and ISO 27001 Stage 1 evidence collection, and audit-firm engagement.
Q1 2027
Target: SOC 2 Type 1 report, ISO 27001 Stage 1 review, and penetration test by an external firm.
August 2027
Target: SOC 2 Type 2 report and ISO 27001 certification for the BetLink platform.

If a date slips, the slip will be published here on the day it is known. We would rather move a date than quietly re-define it.

The person on the other side of this page.

There is one founder. Here is the address you can serve papers at.

Jonathan Luis

Founder, BetLink

BetLink Group Holdings Ltd — Limassol, Cyprus

External counsel: Harris-Kyriakides LLC, Larnaca, Cyprus.

BetLink does not hide behind a generic 'team@'. A regulator, an investor, or an angry affiliate can find a named human and an incorporated Cyprus entity. Counsel is named. Cyprus jurisdiction is named. There is no offshore re-domiciliation planned.

Bug bounty.

We are standing up a private bug bounty programme on Intigriti in late 2026. Scope and reward bands will be published here when it goes live.

Until then, please email security@betlink.ai. We respond within one business day and we do not pursue legal action against good-faith research.
Scope and the canonical security policy live in our /security-policy.txt file, in RFC 9116 format.
A public hall of fame ships with the Intigriti programme launch.

Contactsecurity@betlink.ai Security policy (RFC 9116)