Security you can verify
Controls are layered across identity, application, network and data. No single control is relied upon, every privileged action is logged, and the whole platform is tested independently at least twice a year.
Security policy v2.2 · effective 1 September 2026
Read from the Security policy, not restated. This panel cannot show a recovery objective the document does not.
Defence in depth
Five things that have to be true at once
No single control is load-bearing
Four layers
Identity, application, network and data — each independently sufficient to contain the others
Controls are layered across identity, application, network and data. No single control is relied upon, and every privileged action is logged and reviewed. A control that cannot fail is a control nobody has tested — ours are arranged so the failure of any one is contained by the others.
Phishing-resistant by default
Passkeys and hardware security keys are supported on every account, with one-time codes for step-up verification and new devices confirmed before first use. Sessions expire and can be revoked immediately from your security settings.
Keys nobody holds alone
Stored data is encrypted with AES-256 and keys are managed in hardware security modules under split control. Card data is tokenised and handled within PCI DSS Level 1 scope.
Production nobody walks into
Production runs in isolated environments with least-privilege access, mandatory review on every change, and immutable deployments. Access to production data requires approval and is time-bound.
Tested by people who want it to fail
Security is assessed against ISO 27001 and SOC 2 criteria, with independent testing of the platform and its APIs at least twice a year.
The journey of a session
Where each control actually sits
A list of controls says what exists. This says when each one runs — from the moment you sign in to the moment an incident is closed.
Sign-in
Proved, not typed
Passkeys and hardware security keys are supported on every account, with one-time codes for step-up verification on sensitive actions.
New device
Confirmed before first use
Device binding means an unrecognised device cannot act on your account until you confirm it, and any session can be revoked immediately from your security settings.
In transit
TLS 1.3
Traffic is encrypted with TLS 1.3 between your device and the platform.
At rest
AES-256, keys split
Stored data is encrypted with AES-256, keys are managed in hardware security modules with split control, and card data is tokenised.
Throughout
Scored continuously
Sessions, devices and payments are scored continuously. Unusual patterns trigger step-up verification, a temporary hold, or review by our fraud team.
If something breaks
Detected, then contained
Detection and triage on call at all times, with affected sessions or accounts isolated before anything else happens.
Afterwards
Disclosed and reviewed
Notification to affected customers and regulators within required timeframes, and a post-incident review published in summary where material.
Assessed against
Audited by people who do not work here
PCI DSS Level 1
Card data environment
Assessed by an independent auditor. Attestation reports are available to business customers under NDA through your account contact.
AnnualISO 27001
Information security management
Assessed by an independent auditor. Attestation reports are available to business customers under NDA through your account contact.
Annual surveillanceSOC 2 Type II
Security and availability
Assessed by an independent auditor. Attestation reports are available to business customers under NDA through your account contact.
AnnualPenetration testing
Platform and APIs
Assessed by an independent auditor. Attestation reports are available to business customers under NDA through your account contact.
Twice yearlyRead from the Compliance policy — version 2.0. The cycles shown here and the cycles the document states cannot diverge.
Operational security
Half of it is ours. Half of it is yours.
The controls we run are only half of an account's security. The other half is the two minutes it takes to register a passkey — stated in Your role.
If you suspect unauthorised access
Freeze your cards from the application and contact support immediately. Contact us first and change your credentials second — we would rather hear from you early.
TLS 1.3
Traffic encrypted in transit
AES-256
Data at rest, keys split in HSMs
Twice yearly
Independent testing of platform and APIs
1 business day
Disclosure acknowledged
Questions
What security reviewers ask first
What is your recovery objective if a region fails?
RPO 15 minutes and RTO 4 hours. Backups are encrypted and tested quarterly. Those are the figures the Security policy states — this page cannot state a better one.
Do you support hardware security keys?
Yes. Passkeys and hardware security keys are supported on every account. One-time codes are used for step-up verification on sensitive actions rather than as the primary factor.
How is card data handled?
Card data is tokenised and handled within PCI DSS Level 1 scope. The card data environment is assessed annually by an independent auditor.
Who can access production data?
Access is least-privilege, requires approval, is time-bound, and is logged. Every change reaching production carries mandatory peer review and automated checks, and deployments are immutable.
Will you tell me if there is an incident?
Affected customers and regulators are notified within required timeframes, and a post-incident review is published in summary where material.
How do I report a vulnerability?
Through the security channel in the application, or to security@binkpay.net. We acknowledge within one business day and will not pursue action against good-faith research. Testing must not access other customers’ data, degrade service, or use social engineering against staff or customers.
Will BINK ever ask for my password or one-time code?
Never — not over the phone, not by email, not in chat. If someone does, it is not us. Freeze your cards from the application and contact security immediately.
Boundaries
What BINK will never do
A line a customer can check an approach against is worth more than a paragraph about vigilance. Each of these is stated in the Security policy.
We will never ask for your password. Nor your one-time code or passkey, by any channel.
We do not rely on a single control. Every layer assumes the one above it may have failed.
We do not publish uptime figures here. No approved policy states one, so this page does not either.
We do not pursue good-faith research. Coordinated disclosure is welcome and acknowledged within one business day.
Related
Everything this page is read from
Found a vulnerability?
We welcome coordinated disclosure and acknowledge reports within one business day. Testing must not access other customers' data, degrade service, or use social engineering against staff or customers.