Trust centre
How the platform is built, run and governed
B Group is a technology provider and data processor for regulated businesses. This page describes our security architecture, the certifications we are working towards, the regulations our flows are built to, and how we handle data. We state certification status accurately and claim nothing until it is in hand.
Certification status. No certification listed on this page is held yet. Each is in preparation or planned, with the target period shown. Statements here are pending counsel review.
Security architecture
Hosting and residency
- Production runs in the EU: AWS Frankfurt, with managed AI services such as liveness and face match processed in AWS Ireland.
- UK and Swiss hosting options are planned for clients that require them. No client's data leaves its region.
- Segregated environments for development, test, pre-production and production.
Encryption and keys
- Data at rest is encrypted with customer-managed KMS keys backed by validated hardware security modules; data in transit uses TLS.
- The user's vault is encrypted on the user's device with a key only the user holds. B Group stores ciphertext and the minimum routing metadata and cannot decrypt a vault.
- Verification records and attestations are signed with asymmetric keys held in KMS.
Evidence integrity and retention
- Evidence packs are time-stamped, hashed and signed, and stored with Object Lock retention so they cannot be altered or deleted during the statutory period.
- Retention periods are set per client and jurisdiction and deletion is automatic when a period ends.
- Erasure outside a retention obligation is cryptographic: the data key is destroyed and the ciphertext becomes unrecoverable.
Engineering controls
- All infrastructure is defined as code and deployed through a pipeline that uses short-lived federated credentials; there are no static cloud keys.
- Least-privilege access for every component; one role per function, scoped to the resources it uses.
- Automated agents may open pull requests but never merge; every production release is approved and merged by a named human.
- Changes to verification logic, rule-packs, data handling, encryption, retention or sub-processors pass through documented approval gates and are logged.
How data is transmitted, held and encrypted
Unlockable only through the highest level of secure connection.
In transit
TLS 1.3 with modern cipher suites and HSTS everywhere. Machine clients authenticate with OAuth 2.0 client credentials plus a metering key, and optionally mutual TLS with client certificates. Webhooks are signed with HMAC-SHA256 and time-stamped so a replayed or tampered delivery is rejected.
For people
Compliance teams sign in with passkeys (FIDO2 / WebAuthn) or multi-factor authentication, with roles and permissions per person. Vault users unlock their own vault only with their passkey; there is no password to phish and no key for us to lose.
At rest
Envelope encryption: every record has its own data key under AES-256-GCM, wrapped by customer-managed keys in FIPS 140-3 validated hardware security modules, rotated automatically and never exportable. Vault contents are additionally encrypted on the user's device under a key only the user holds.
Integrity
Evidence packs are hashed, signed with asymmetric keys held in the HSM and stored under Object Lock, so a record cannot be altered or deleted inside its retention period. Every access is logged to an immutable audit trail.
Minimisation and residency
Field-level encryption for the most sensitive attributes, identifiers rather than personal data in workflow state and model sessions, retention set per client and jurisdiction, and no client data outside its region.
Erasure, backups and insurance
Erasure is cryptographic: destroy the data key and the ciphertext is unrecoverable, in backups too. Backups are encrypted under separate keys. Insurance of the data held on your behalf is available on request.
Certification roadmap
| Certification or assessment | Scope | Status | Target |
|---|---|---|---|
| ISO/IEC 27001 | Information security management system | In preparation | H1 2027 |
| SOC 2 Type I | Security, availability and confidentiality controls | In preparation | H1 2027 |
| SOC 2 Type II | Operating effectiveness over an observation period | Planned | Early 2028 |
| ETSI TS 119 461 conformity assessment | Identity proofing at the "high" level, directly or with a qualified trust service provider partner | Planned | 2027-28 |
| UK DIATF 1.0 and DVS registration | UK Digital Identity and Attributes Trust Framework; Digital Verification Services register | Planned | Before UK launch |
| iBeta ISO/IEC 30107-3 (liveness) | Presentation-attack detection testing | Only if we deploy our own liveness | 2028 option |
| Penetration testing | Annual independent tests plus tests after material change | Scheduled | Pre-launch and annually |
| Data protection impact assessment | Before launch and after every material change | In preparation | Before launch |
At launch, liveness and face match are delivered by a licensed third-party component that carries its own conformance testing. We state the coverage of licensed components and the assurance level of each method rather than claiming them as our own.
Regulatory alignment
Our clients are the obliged entities; our job is to make their compliance demonstrable and to be the kind of vendor they are allowed to use. Flows and evidence packs are mapped to the following.
- EBA remote-onboarding guidelines (EBA/GL/2022/15). Pre-implementation assessment pack, document security-feature checks, tamper and screen-reproduction detection, liveness in unattended flows, time-stamped records readable for ex-post verification.
- AMLA customer-due-diligence standards. Controls that the presenter is the document holder, secure communication, image quality, abort on interruption, time-stamped copies retained for ex-post verification. A fresh liveness check on every vault reuse follows directly from these.
- EU AML Regulation (2024/1624), applying from 10 July 2027. Rule-packs and evidence packs built to the identification, reliance, outsourcing, record-keeping and data-protection articles; standard reliance agreement for the network; human review of adverse decisions.
- MiCA (2023/1114) and the Transfer of Funds Regulation (2023/1113). MiCA/TFR rule-pack and Travel Rule data exchange.
- DORA (2022/2554). An Article 30 contract addendum (standard and critical-function versions), register-of-information data for your register, incident-notification SLAs and an exit and portability plan. Available on request.
- GDPR. Explicit consent for biometric comparison, biometric templates under the user's own key, minimal retention, a DPIA, an appointed Data Protection Officer, processor terms for clients and a controller role for the vault.
- UK Money Laundering Regulations and JMLSG; FINMA Circular 2016/7. UK rule-pack scheduled for H2 2027; Swiss rule-pack scheduled for 2028.
B Group does not provide payments, accounts, cards, custody, exchange, lending or any other financial service; where a client needs such services we refer them to partners.
Sub-processors
Verification uses a small number of specialist sub-processors: a licensed document-authenticity SDK, a cloud liveness and face-match service processed in the EU, screening data providers (official EU, UN, OFAC and UK lists, a commercial PEP and adverse-media feed, and OpenSanctions under commercial licence), a crypto-asset analytics provider, and our cloud infrastructure provider. The full list with locations and purposes is published on contract and maintained in a form clients can load straight into their DORA register of information. Changes to sub-processors pass through our approval gates and are notified in advance.
Data residency and retention
- Where data is processed
- EU (Frankfurt, with Ireland for managed AI services). UK and Swiss regions planned. Data stays in the client's region.
- Client evidence packs
- The client's regulatory record. Retained for the statutory period (five years after the end of the relationship under the AMLR, extendable on a supervisor's order) and deleted automatically when the period ends.
- The user's vault
- The user's own record, under the user's key. Erasable by the user at any time by cryptographic erasure.
- Biometric templates
- Retained only as long as the flow needs them unless the user chooses a vault, in which case the template lives inside the vault under the user's key.
- Logs and audit trails
- Retained for the period required by our security programme and client contracts, encrypted and access-controlled.
People, disclosure and status
Accountable humans
Named human officers hold the seats regulated buyers expect: a Chief Executive Officer, a Data Protection Officer, an Information Security Officer and a Compliance Officer. Each has defined authority over the approval gates that touch their area. Contact details are provided on contract.
Responsible disclosure
If you believe you have found a security issue, write to security@bgroup.io. We acknowledge reports promptly, work with you on remediation and do not pursue researchers who act in good faith.
Service status
Uptime, incident history and maintenance notices are published on the status page. Sev-1 incidents receive a response within two hours.