/// Security & compliance

Security is a property of how a system is built and run.

Protocore builds the software layer for payments, AI, and blockchain systems. This page states plainly how we handle data, how the software is operated, and where the regulated line sits — no badges to wave, just the posture we build to.

/// Data & privacy

We collect what a flow needs, and no more.

The systems we build are designed around data minimization: each flow captures only the fields it needs to do its job, kept only as long as it's needed. Where we host, we host in the EU — production runs in AWS eu-central-1, Frankfurt — and we build to align with GDPR practices: a lawful basis for what's processed, honoring access and deletion requests, and keeping personal data out of logs and analytics by default.

  • [ 01 ]Data minimization by default
  • [ 02 ]EU hosting — AWS eu-central-1 (Frankfurt)
  • [ 03 ]GDPR-aligned handling: lawful basis, access, deletion
  • [ 04 ]Personal data kept out of logs and analytics
/// How it's operated

Least-privilege access, and privileged actions that require a reason.

The software we ship is instrumented from the first commit — logs, metrics, and traces — so what happens in production is visible, not inferred. Access follows least privilege: every actor, human or service, gets the narrowest permission that lets it do its job. Sensitive operator actions ask for a reason before they run and leave an audit trail of who did what, when, and why. This is the model behind Protocore Center, our operator console — the same posture we build into every system.

  • [ 01 ]Instrumented by default — logs, metrics, traces
  • [ 02 ]Least privilege for every actor, human or service
  • [ 03 ]Reason-required privileged actions
  • [ 04 ]An audit trail of who did what, when, and why
/// Separation of concerns

We build the software. The regulated line stays with the licence.

A payment product is two things fused: the regulated permission to hold or move money, and the software that instructs, reconciles, and shows it. Protocore builds the software. The regulated activity — holding funds, issuing accounts, moving money — sits with the operator's own licence or a licensed partner: a bank, an EMI, or a payment institution. We build the flows to fit whatever regulated rails you bring; we are not, and no software is, a substitute for that permission.

  • [ 01 ]Protocore builds the software, not the licence
  • [ 02 ]Regulated activity sits with the operator or a licensed partner
  • [ 03 ]Card data handled so it never touches your servers
  • [ 04 ]Strong customer authentication built into the payment flow
/// Practices

The habits behind a system you can trust.

Concrete practices we build in — stated as mechanics, not badges.

Card data off your servers

Card details are handled by the payment rail and tokenized, so raw card numbers never touch the operator's own infrastructure.

Strong customer authentication

SCA is built into payment and sign-in flows — a second factor where the rail or the risk calls for one, not bolted on afterward.

Encrypted in transit

Traffic runs over TLS end to end; secrets and credentials live in managed stores and instance roles, never in source.

Isolated by tenant

Where one system serves many operators, each tenant's data is separated by access control so one tenant can never read another's.

/// Responsible disclosure

Found something? Tell us.

If you believe you've found a security issue in a Protocore system, email us and we'll work it with you. We aim to acknowledge reports quickly, keep you posted while we fix, and credit you if you'd like once it's resolved. Please give us a reasonable window to remediate before disclosing publicly, and don't access or alter data that isn't yours while testing.

/// Email security
security@protocore.io
[ 01 ]
Report

Email security@protocore.io with what you found and how to reproduce it.

[ 02 ]
Acknowledge

We confirm we've received it and start looking, usually within a couple of business days.

[ 03 ]
Fix

We remediate and keep you posted on progress through to a resolution.

[ 04 ]
Credit

With your okay, we credit you once the issue is resolved.

/// Questions

Security questions we're asked first.

  • We describe our security as practices, not badges. Protocore builds the software layer; where a regulated scheme applies — card handling, for instance — the certified boundary sits with the payment rail or the operator's licensed partner, and we build so card data never touches your servers. If a specific attestation matters for your programme, tell us and we'll map out who holds what.

  • In the EU. Production runs in AWS eu-central-1 (Frankfurt). We build to align with GDPR practices — data minimization, a lawful basis for processing, and honoring access and deletion requests.

  • The licence. Protocore builds the software that instructs and reconciles money movement; holding or moving funds sits with your own licence or a licensed partner — a bank, EMI, or payment institution. No software is a substitute for that permission.

  • Least privilege for every actor, and privileged actions that require a reason and leave an audit trail. Everything is instrumented, so who did what is a matter of record rather than reconstruction.

  • Email security@protocore.io. We acknowledge quickly, keep you posted while we fix, and credit you if you'd like once it's resolved.

Have a security question we didn't cover?

Tell us what you need to see. We'll answer with specifics — architecture, data flows, and who holds which line.

Contact us