Security

01Our stance

We process bank statements for regulated lenders. That makes security a condition of doing business, not a feature.

This page describes what we actually do today, and — in section 9 — what we have not built yet. We publish the second list because you are going to send us a vendor questionnaire anyway, and because a supplier who tells you their gaps up front is easier to trust than one who does not.

02Data minimisation as the primary control

The most reliable way to protect a document is not to be holding it. Our architecture is built around that.

• Source documents are deleted within 72 hours by an automated lifecycle policy. Customers can set it shorter. A separate job audits for any object exceeding its window and alerts us if one exists.
• Backups honour the same clock, so deletion is not quietly undone by a restore point.
• Derived data only after that: signals, evidence references, requested extracted figures, and one-way fingerprints.
• Redaction before third parties. The component that writes plain-language summaries receives reason codes and redacted specifics. It never receives names, account numbers or full transaction narration, and it runs against a zero-retention endpoint.
• The fingerprint network carries no personal data. Hashes and layout vectors only. See the privacy policy.

03Handling files from people trying to defeat us

Our input is untrusted documents supplied by applicants, some of whom are actively adversarial, parsed by libraries with a long history of vulnerabilities. We treat this as our highest technical risk.

• Parsing runs in an isolated worker with no network egress, a read-only file system apart from scratch space, dropped capabilities, hard memory limits and wall-clock timeouts.
• One process per document, destroyed afterwards. An interpreter is never reused across documents or across customers.
• File type is determined from content, never from the extension or the declared MIME type.
• We reject or quarantine files carrying embedded scripts, launch actions, embedded executables, absurd object counts, pathological nesting, or decompression ratios consistent with a bomb.
• Page count, file size and image dimensions are capped before any decode happens.
• Dependencies are scanned continuously and PDF libraries are patched on priority.

04Encryption and network

05Tenant isolation

• Every record carries a tenant identifier, and isolation is enforced at the data access layer rather than left to individual queries. Cross-tenant reads are structurally prevented, and tested.
• Object storage is partitioned per tenant.
• Queues are isolated per tenant, so one customer's bulk batch cannot starve another's real-time traffic.
• Engine versions are pinned per customer, so an update to one does not silently change results for another.

06Access control and logging

• Named individual accounts only, multi-factor authentication required, no shared credentials.
• Least privilege by default. Production access is limited to the people who need it and reviewed quarterly.
• All production access is logged, including any access by our staff to a customer document.
• Append-only audit trail of every document processed, every signal produced, every engine version used, and every human who viewed a document. This exists for your disputes as much as for our debugging.

07Resilience and incident response

• Fail open. If we are unavailable your decisioning continues on your prior process. We are architecturally incapable of blocking a disbursement.
• Graceful degradation. If a layer is unavailable, the remaining checks run and the response's coverage field records what was skipped. You never get a clean score built on checks that did not happen.
• Encrypted backups with tested restores, on a schedule that respects our retention limits.
• A written incident response plan, rehearsed. On a breach affecting your data we notify you without undue delay and within the timeline in our data processing agreement, with what we know, what we are doing and what you need to do.

08Data protection compliance

We act as processor for customers and controller for our own website and business data. We support the Nigeria Data Protection Act 2023 and, for customers within scope, the GDPR.

• A data processing agreement is available and can be signed before you send a single document.
• Records of processing activity are maintained.
• Sub-processors are documented in the privacy policy, with 30 days' notice and a right to object before any change.
• Standard Contractual Clauses or equivalent for cross-border transfers, with in-region processing available on Enterprise agreements where a regulator requires it.
• We will support your DPIA with the technical detail you need.

09What we do not have yet

Vepiom is an early company. Some controls a large vendor would list are not in place, and we would rather you learn that here than discover it in a questionnaire.

If a gap here blocks a deal, say so. We would rather build the control than lose the reason to.