Security

Data storage and hosting

• ✓

  European data residency

  All customer and registration data is stored on cloud infrastructure hosted within the European Union. Data does not leave EU jurisdiction during normal operation.

• ✓

  Encryption in transit

  All traffic between users and the application is encrypted using TLS 1.2 or higher. HTTP Strict Transport Security (HSTS) is enforced across all endpoints.

• ✓

  Encryption at rest

  All database storage is encrypted at rest using AES-256. Backups are encrypted and stored within the same geographic region.

• ✓

  Certified infrastructure

  Our cloud infrastructure providers hold recognised independent security certifications. Certification documentation is available on request for enterprise evaluation purposes.

Access controls

• ✓

  Row-level data isolation

  Database access control is enforced at the row level. Users can only read and write data belonging to their own organisation. There is no logical path for one customer's data to be visible to another.

• ✓

  Privilege separation

  Application components operate under separate credentials with only the permissions each requires. Administrative credentials with elevated privileges are never exposed to client-side code.

• ✓

  Credential protection

  Sensitive credentials stored by the application (such as email connection passwords) are encrypted using AES-256-GCM before storage. Encryption keys are stored separately from the data they protect.

• ✓

  Internal access

  Internal team access to production systems is restricted on a need-to-know basis and protected by multi-factor authentication. Access is reviewed periodically.

Application security

• ✓

  Input validation and injection prevention

  All user inputs are validated server-side. Parameterised queries are used throughout — the application does not construct raw queries from user input.

• ✓

  Rate limiting and bot protection

  Public-facing endpoints are protected by rate limiting. The interest registration form includes a challenge verification layer to prevent automated submissions.

• ✓

  Dependency hygiene

  Production dependencies are kept minimal and reviewed for known vulnerabilities. We do not include client-side analytics or tracking scripts that could introduce third-party risk.

• ✓

  No payment execution

  APHubNet generates and exports payment files but does not execute bank transfers or hold payment funds. This is a deliberate architectural boundary — the payment instruction leaves the platform and is executed by your bank under your control.

Audit trail and compliance design

APHubNet is being designed with auditability as a first-class requirement. Every material action in the platform — invoice status change, approval decision, payment file export, supplier bank detail update — will be timestamped, attributed to a named user, and stored permanently. Audit records cannot be edited or deleted by application users.

The platform is designed to support SOX-aligned controls for mid-market finance teams, including segregation of duties between the person who approves an invoice and the person who initiates the payment export, and between those who can onboard suppliers and those who can approve payments.

Specific product-level compliance certifications (SOC 2, ISO 27001) will be pursued as the platform matures and customer demand justifies the investment. In the meantime, prospective customers with specific audit requirements are welcome to discuss these with us.

Supplier fraud controls

Invoice redirection fraud — where a supplier's bank details are changed by a fraudster before a payment run — is one of the most common and costly fraud vectors in accounts payable. APHubNet treats this as a platform-level problem, not a policy problem.

• ✓

  Bank detail change hold

  Any change to a supplier's payment details triggers a mandatory hold and secondary approval before the updated details can appear in a payment proposal.

• ✓

  First-payment controls

  New or recently amended supplier bank details are subject to a configurable hold period before inclusion in any payment run.

• ✓

  Anomaly signals

  The platform will surface signals for unusual invoice patterns — near-duplicate vendor names, amounts outside historical range, IBANs that differ from prior invoices — before any posting or payment action.

Responsible disclosure

If you discover a potential security vulnerability in the APHubNet website or application, please report it to security@hidbrain.com before disclosing it publicly. We aim to acknowledge all reports within 72 hours and will work with you to understand and address the issue before any public disclosure.

Questions

For security questions, infrastructure certification documentation, or to discuss specific requirements for an enterprise evaluation, contact us at security@hidbrain.com.

Hidbrain Ltd · Company No. 12170656 · VAT GB343581107 · Registered in England and Wales