How Banqloop is built, and where it stands

1. About this page

This page describes, in plain terms, how the Banqloop road and drainage defect platform is engineered and operated, what data it handles, and which vendors touch that data. It reflects the state of the deployed platform and our internal control documentation as of the date above.

This page is not a certification, an audit report, or legal advice. Banqloop has not completed a SOC 2 examination and no independent auditor has opined on the controls described here. The claims below are drawn from our own engineering documentation and the running system, not from an outside review.

Where our posture has known gaps, we name them (see Honest limitations) rather than presenting an unfinished program as a complete one.

2. How the platform runs

These practices are operating in production today, with their evidence defined in our internal control matrix:

• Reviewed changes only. All production changes flow through reviewed pull requests with automated checks — lint, typecheck, tests, build, and a dependency/config vulnerability scan that blocks on critical findings — merged onto protected branches.
• Tenant-scoped access control. Every API route is gated by role-based permissions; roles and data are scoped per tenant, and administrative console access is protected by multi-factor authentication.
• Append-only audit trail. Security-relevant administrative actions are recorded in an audit ledger that the application cannot alter or delete: updates and deletions are revoked at the database and blocked by triggers.
• Device identity we control. Each edge device authenticates to our broker with a unique mTLS client certificate whose identity is stamped server-side from the device’s tenant binding — a device cannot choose or forge its own identity, and cannot read another tenant’s data.
• Encryption in transit and at rest. Device↔cloud, browser↔cloud, and cloud↔database connections are all TLS-encrypted, and third-party integration credentials are stored encrypted with envelope encryption.
• Careful fleet updates. Configuration changes are delivered as signed, revision-gated overlays that are health-checked and automatically reverted on failure; software releases are canary-gated and rolled back if a health check fails, and every published release artifact is integrity-verified (SHA-256) against the bytes the public endpoint actually serves.
• Monitoring that watches the data path, not just heartbeats. Fleet alerting distinguishes a device being online from data actually flowing, so a silently broken pipeline is surfaced rather than hidden behind healthy heartbeats.

Our internal control matrix tracks 22 controls against the Trust Services Criteria. As of the date above, 14 are operating, 4 are operating with a named gap, 3 are not yet operating, and 1 is scheduled.

3. Data we handle

The platform processes infrastructure-location data — where a road or drainage defect is — and operational telemetry about our own devices:

• Detection records: the defect class (e.g. pothole), severity, confidence, bounding box, the defect’s GPS location captured from the vehicle’s fix at detection time, the road name, and model version.
• Detection imagery: narrow 800×600 per-lens camera frames of the road surface, captured at the moment a defect is detected — not continuous video.
• Device health: device identifiers, temperature, storage, and last-seen times — devices are vehicles, not people.
• Operator accounts and pilot enquiries: standard account and sales-lead information for dashboard users and website visitors.

We do not process:

• license-plate data (see the next section);
• precise biometric identifiers, or any biometric processing;
• payment card data;
• continuous location histories of any person.

GPS is acquired only to geo-locate a defect event. Detection data lives in a tenant-scoped PostgreSQL database on a private network; imagery is served from object storage behind a CDN.

4. Not a license-plate system

Banqloop’s platform is not an automated license plate recognition (ALPR) system. By design and by verifiable construction, it:

• does not read, decode, or extract license plate data from any frame;
• does not index, store, or search license plate data anywhere;
• does not transmit plate data off the vehicle — the event contract has no plate field;
• does not associate any detection with an identified or identifiable member of the public; and
• performs no biometric processing of any kind.

Street-level images may incidentally contain parked or passing vehicles whose plates are visually present — an unavoidable property of photographing streets. Those frames are narrow, defect-moment captures that no pipeline component ever processes for plates.

5. Subprocessors

The production estate runs on Google Cloud (us-east1, USA) for compute and data — including the PostgreSQL database with spatial extensions, the certificate authority that issues device identities, key management, and secret storage — and on Cloudflare for edge delivery, device-facing services, and object storage.

Two additional vendors provide supporting services without touching fleet data: transactional email delivery (invite and notification emails) and web mapping tiles for map display.

The full subprocessor list, data categories, and our current data processing agreement template are available on request.

6. Honest limitations

We would rather a reviewer know the state of our program than infer completeness from a polished page. As of the date above:

• No third-party attestation yet. We have not completed a SOC 2 examination; nothing on this page is an auditor’s opinion. Our internal control matrix is built to make that examination straightforward if and when we begin it.
• Data retention and deletion are not fully built. We have not yet implemented an automated retention schedule with a deletion workflow across all stores; data is not currently deleted automatically on a schedule.
• Periodic access reviews are not yet operating. Re-attestation of admin users, roles, and API keys on a fixed cadence is defined but not yet running as a routine process.
• Our compliance documentation is a working draft. The control matrix, data-flow disclosure, and related documents are internally maintained and pending final management and legal review; details may change.

Current-state details for a specific procurement or security review are available on request — including the individual control records behind the summary above.

7. Contact

Questions about security, data handling, or compliance: hello@banqloop.com. We can provide our data processing agreement template, the detailed control matrix, and current subprocessor documentation as part of a procurement review.