Bahrain BusBahrain Bus
Live demoBack office
01Architecture · Integrations

Designed to connect with the services BPTC’s scope names. Providers marked “e.g.” are examples — selection follows BPTC procurement.

Explore the key flows
Bahrain Bus
BPTC platform
Wallet, ledger & validation

BPTC platform connects to 8 external services (SOW Sections 10 and 13): Payment gateway (BENEFIT), Acquiring bank, Licensed payment provider, SMS aggregator & push, Mobile device management, Timetable (GTFS), Journey planners, Maps & navigation provider. Not connected: Existing fare collection and Existing vehicle location.

Payment gateway (BENEFIT)
Required

Purchase, top-up, refunds and settlement files

BENEFIT debitVisa · Mastercard 3-D SecureBenefitPayApple PayGoogle Pay
Two-way. Purchase, top-up, refunds and settlement files. Card data never enters BPTC systems; credit only on server-to-server confirmation.
Acquiring bank
Provider TBC

Certified card-tap component · settlement reporting

Certified payment component
Two-way. Certified payment component for single-trip card tap, and settlement reporting. Paid directly to the bank; BPTC keeps only a boarding record and the bank’s reference. A Should item (fleet rollout); availability of a certified component for the validator is a Section 16 clarification.
Licensed payment provider
Subject to legal confirmation

Funds-holding structure (PAY-06)

Two-way. Stored-value funds held and settled through a licensed payment provider structure (PAY-06). The licensed provider structure is subject to BPTC’s legal confirmation.
SMS aggregator & push
Required

One-time passwords, receipts and alerts

e.g.SMS aggregatorAPNs / FCM push
From the platform. One-time passwords, receipts and alerts. One-time passwords by SMS; receipts and alerts by SMS or push.
Mobile device management
Required

Enrolment, kiosk mode, attestation, remote wipe

e.g.Samsung KnoxMicrosoft Intune
Two-way. Enrolment, kiosk mode, attestation and remote wipe for validators. A validator that fails attestation must stop validating.
Timetable (GTFS)
Required

Import from BPTC's published timetable

BPTC published GTFS
Into the platform. Import from BPTC's published timetable data. Each import is versioned; GTFS route, trip and stop IDs become the platform’s own keys.
Journey planners
Optional

Real-time feed, where BPTC chooses to publish

GTFS-Realtimee.g.Google MapsMoovit
From the platform. Publication of the real-time feed, where BPTC chooses to publish. GTFS-Realtime vehicle positions, trip updates and service alerts from a cached endpoint.
Maps & navigation provider
Required

Driver navigation with offline map data

e.g.OpenStreetMap-based maps
Into the platform. Driver navigation, with offline map data. Provider, licence model and offline map approach: clarifications requested in Section 16.
Existing systems · No integration required (§2.1, §13)
Existing fare collection
Cash and GO Card continue unchanged
No integration
Existing vehicle location
Runs alongside, not integrated
No integration

Any limited data exchange with these systems, such as for reporting or reconciliation, would be specified by BPTC (§1).

Examples for illustration; provider selection is pending and subject to BPTC procurement. No commercial relationship is implied. Integrations per SOW Sections 10 (PAY-06) and 13; existing fare collection and vehicle location systems need no integration.

02System architecture

Four layers, one source of truth. Channels reach the core only through the edge; data services stay private.

Passengers and staff come in through a WAF-protected edge, validators through mutual TLS per device. Behind it, fifteen backend services and fraud detection share an append-only ledger in PostgreSQL, standard messaging, a reporting replica and hardware-backed keys.

Arrow keys move between services. Enter, Space, a click or a tap pins a service and shows its details; Escape clears it.

Tap a service for its details and the services it talks to.

HTTPS through the WAFMutual TLS from validatorsPrivate links to data services
Channels

Apps and portals (§2)

PA-01
Passenger app
iOS & Android · Arabic & English
ADM-01
Admin back office
Fares, fleet, fraud cases, GTFS, audit
CP-01
Counter portal
Cash sales, top-up, recovery, refunds
DV-01
Driver validator
Rugged Android tablet · kiosk mode
Edge & security

WAF, DDoS, mutual TLS, versioned APIs (SEC-03, SEC-04, BE-16)

SEC-01
Public edge
WAF · DDoS protection · TLS 1.2+
BE-16
Versioned APIs
Documented with OpenAPI
SEC-03
Device gateway
Mutual TLS per validator · revocable
Core services

Backend services BE-01 – BE-15 and fraud detection (§5, §6)

Identity & devices
BE-01
Identity & access
Passenger OTP · staff SSO + MFA · RBAC
BE-05
Device binding
Bind · re-issue · revoke
BE-04
Credential service
Signed, device-bound · keys in HSM
Wallet & payments
BE-08
Payment orchestration
Purchase · top-up · refunds · settlement
BE-13
Concession workflow
Evidence · review · expiry · renewal
BE-03
Wallet & entitlement ledger
Append-only · double-entry
Notifications, fraud & insight
BE-14
Notifications
SMS one-time passwords · push
FR-01
Fraud detection
Rules · risk score · cases — off the decision path
BE-15
Analytics & reporting
On a separate reporting replica
Ticketing & validation
BE-07
List distribution
Blocklists · deny lists · consumed trips
BE-02
Product & fare engine
Configured without an app release
BE-09
Offline synchronisation
Idempotent ingestion · zero loss
BE-06
Validation engine
Signature · entitlement · rules · replay
Timetable & real time
BE-11
Route telemetry
Route matching · adherence · km
BE-10
Timetable (GTFS)
Import · versioning · duties
BE-12
Real-time feed
GTFS-Realtime · cached endpoint
Data & keys

PostgreSQL, messaging, reporting replica, HSM, logging (NFR-09, SEC-01/02/09/10)

SEC-01
Key vault · HSM
Signing keys · customer-managed keys
SEC-09
Logging & SIEM
Central logs · security monitoring
SEC-10
Immutable backups
Recovery region outside the Gulf
NFR-09
PostgreSQL
Operational data · ledger · private endpoint
BE-15
Reporting replica
Read-only copy for analytics
NFR-09
Event messaging
Standard messaging · durable queues

Services map to SOW Section 5 (BE-01 – BE-16) and Section 6 (fraud detection, which never makes a boarding or payment decision on its own). Hosting per NFR-07 – NFR-09.

03Key flows

Follow a tap, a top-up or a timetable through every service it touches.

Pick a flow and watch its path light up step by step. Each step names the requirement it meets, and the ledger postings are the ones the prototype's back office shows.

A passenger adds BHD 5.000 to the wallet. Card details stay with the gateway; the wallet is credited only when the gateway confirms server to server.

Step 1 of 9
Top-up request
Passenger app → Public edge

The app sends the amount with an idempotency key, so a retry can never charge or credit twice.

PAY-04

Outcome: Balance credited exactly once, receipt sent, and a fresh signed balance credential on the phone.

Top up in the passenger app
Top-up via the payment gateway. Step 1 of 9: Top-up request
04Online and offline

Fare collection never stops because of a connectivity failure.

Validators decide against cached keys, lists and BPTC's offline policy, keep working for at least 72 hours without connectivity with no transaction loss, and reconcile each queued event exactly once when signal returns.

  • Live event
  • Decision
  • Queued (encrypted)
  • Fraud check
  1. 01Online
  2. 02Offline
  3. 03Signal back
Passenger app
QR, or NFC on supported Android; works without mobile data
Driver validator
Online
Rugged Android tablet · kiosk mode
Cached on the device
Keys k2026-10BlocklistDeny listConsumed single tripsOffline policy · limits
Queued events (encrypted)
0
Without signal 0 h of at least 72 h
Device gateway
Mutual TLS per validator · revocable
mTLS session up
Validation engine
Signature · entitlement · rules · replay
Decided
0
NFR-03: end-to-endp95 < 1.5 s
Decides each online boarding
Offline sync
Idempotent ingestion · zero loss
Ingested
0
Dupes
0
Each event id ingested once
Wallet ledger
Append-only · double-entry
Online
0
Synced
0
Dr wallet:P-1002Cr revenue:fares
Fraud detection
Off the decision path
Checked
0
FR-02
Checks each synchronised event

Simulated. Stored value is deducted offline against a signed balance credential, within a per-account offline spending limit (prototype default BHD 1.500, configurable under OFF-01). Bank card taps need signal: the bank authorises each tap.

Required behaviour in each condition

SOW §7
  • Passenger offline, validator online

    Full online validation. Passenger data is never required at boarding.

    Online
  • Validator offline

    Validate against cached keys, lists and the approved offline policy; queue events encrypted on the device; reconcile on reconnection.

    Offline mode
  • Stored-value deduction offline

    Deduct against a signed balance credential, within a configurable per-account offline spending limit; any resulting shortfall recovered at the next top-up, subject to BPTC policy.

    Offline mode
  • Single trips offline

    Accepted only within policy limits, and checked against the cached consumed single-trip list.

    Offline mode
  • Bank card tap without signal

    Not available, as the bank authorises each tap. QR, NFC wallet and cash remain available.

    Not available
  • Backend unavailable

    Validators continue in offline mode; queued events reconcile once service is restored.

    Offline mode
  • Counter and admin portals

    Online only.

    Online only

Offline requirements

OFF-01 – OFF-04
  • OFF-01

    Offline duration, permitted products and spending limits configurable by BPTC.

    Prototype default: 72 h offlineBHD 1.500 spending limit
  • OFF-02at least72h

    Validators tolerate at least 72 hours without connectivity with no transaction loss.

  • OFF-03

    Validators synchronise opportunistically whenever signal is available, not only at the depot.

  • OFF-04

    Alerting when a validator has been offline beyond a configurable threshold.

05Deployment & security

Hosted in Azure UAE North, recoverable from Europe and secured end to end.

Infrastructure as code for development, test and production. Containers, PostgreSQL and standard messaging keep the core portable; keys stay in hardware; every validator has its own mutual-TLS identity; and an independent third-party penetration test runs before go-live and annually.

Encrypted, immutable backup copies replicate from Azure UAE North, the primary region, to the recovery region, Azure region in Europe.

Azure UAE North

Primary region

Subject to BPTC's data residency confirmation.

NFR-07
Infrastructure as code
Development
Test
Production
Infrastructure defined as code, with development, test and production environments.NFR-08
WAF & DDoS protection
Public edge for apps and portals
e.g.Azure Front Door WAFAzure DDoS Protection
SEC-04
Containers
Stateless services, portable between regions and providers
e.g.AKS (Kubernetes)
NFR-09
Standard messaging
No proprietary dependency in the core
e.g.AMQP brokerKafka-compatible
NFR-09
Key vault · HSM
Signing keys and customer-managed keys
e.g.Azure Key Vault Managed HSM
SEC-01SEC-02
Managed identities
No shared or embedded credentials
e.g.Microsoft Entra ID
BE-01SEC-05
Monitoring & SIEM
Latency, device status, security events
e.g.Azure MonitorMicrosoft Sentinel
SEC-09NFR-10
PostgreSQL
Private endpoint · customer-managed keys
e.g.Azure Database for PostgreSQL
NFR-09SEC-01SEC-04
Reporting replica
Analytics off the transactional path
BE-15
Immutable backups
Copied to the recovery region
SEC-10

Azure region in Europe

Recovery region

Recovery copies and immutable backups outside the Gulf, with agreed RPO and RTO.

NFR-07SEC-10
Backup copies
Immutable, outside the Gulf
SEC-10
Recovery copies
Held in Europe
NFR-07

Recovery objectives

To be agreed

RPO data that could be lost; RTO time to restore service.

SEC-10

The SOW specifies Microsoft Azure, with UAE North as the primary region subject to BPTC’s data residency confirmation, and recovery copies in Europe (NFR-07, SEC-10). Service and product names marked “e.g.” are examples for illustration; selection is pending and subject to BPTC procurement. No commercial relationship is implied.

Thirteen security controls, each traceable to SEC-01 – SEC-13.

SOW Section 11 · every control is a Must

Data & keys

  • SEC-01

    TLS 1.2+ in transit; encryption at rest with customer-managed keys

  • SEC-02

    Credential signing keys in hardware-backed storage, rotated on a schedule

Devices & apps

  • SEC-03

    Mutual TLS for each validator, individually revocable

  • SEC-06

    App hardening, tamper and root/jailbreak detection, certificate pinning

  • SEC-07

    MDM with kiosk lockdown, remote wipe and attestation

Access & privacy

  • SEC-05

    Role-based access, MFA and managed identities; no shared or embedded credentials

  • SEC-12

    Bahrain Personal Data Protection Law: minimisation, retention, data subject rights

  • SEC-13

    No developer access to production data

Platform & resilience

  • SEC-04

    Private endpoints for data services; WAF; DDoS protection appropriate to a single-region workload

  • SEC-09

    Centralised logging and security monitoring, with detection rules for Section 6 cases

  • SEC-10

    Immutable backups and a recovery region outside the Gulf, with agreed RPO and RTO

Assurance

  • SEC-08

    Threat modelling, static and dynamic testing, dependency and container scanning, SBOM, signed builds

  • SEC-11

    Independent third-party penetration test before go-live and annually

Acceptance targets

SOW §12§7
  • NFR-01

    <0.5s

    Median QR recognition on the reference device in daylight (99% within 1.0 s)

  • NFR-02

    <0.5s

    Median NFC wallet tap decision

  • NFR-03

    <1.5s

    Online validation, end to end (p95)

  • NFR-04

    99.9%

    Monthly availability of validation and purchase

  • NFR-05

    50,000

    Boardings a day on 100 vehicles, with ≥ 3× peak headroom

  • NFR-06

    2.1AA

    WCAG accessibility for apps and portals

  • OFF-02

    72h

    Validator operation without connectivity, no loss

06Scope boundaries

Built alongside what already works. Cash and GO Card continue unchanged.

BPTC's scope leaves these out. The platform runs alongside the existing fare collection and vehicle location systems, from the pilot on 5 to 10 buses through fleet rollout.

SOW Section 2.1 · Out of scope6 items

  • Replacement of, or integration with, BPTC's existing fare collection and vehicle location systems

    Out of scope

  • Engine or vehicle telematics, and driver behaviour scoring

    Out of scope

  • Passenger information displays at bus stops

    Out of scope

  • Open-loop account-based bank card ticketing with fare capping

    Bank card tap is for single trips only (DV-05).

    Out of scope

  • Storage, processing or transmission of card data by BPTC systems

    Cards stay with the gateway and the certified component (PAY-02, PAY-05).

    Out of scope

  • Reading existing GO Cards on the validator

    Unless addressed as a clarification under Section 16.

    Out of scope

From SOW Section 2.1. Any limited data exchange with existing systems, for example for reporting or reconciliation, would be specified by BPTC (Section 1).

Clickable prototype

See it working. Every surface runs on the same simulated backend.

Open the live demoOpen the back office