Is Your Bank's Pigmy Data Safe? How ezPigmy Protects Every Transaction

We've had bank managers ask us flat out: "Can your engineers read our members' pigmy transaction data? Is our data sitting on a foreign server? What if someone hacks the system?"

These are exactly the right questions to ask before trusting any software with your bank's financial records. Here is the honest, detailed answer — plain English for your management team, with the technical detail your IT officer needs.

---

Your Data Never Leaves India

ezPigmy runs on Indian servers. Every pigmy transaction your agents collect — every deposit amount, every member account, every agent collection entry — is stored in India.

Not on American servers. Not on European servers. Not on Chinese infrastructure.

This is not an afterthought. Indian data localisation is built into our infrastructure by design, consistent with the Reserve Bank of India's guidance that regulated entities should keep payment data on domestic soil.

Your members' data is stored in India. It has never touched a foreign server.

---

Only Your Bank Can Ever See Your Data

Banks on the ezPigmy platform do not share a data pool. Your pigmy records are completely separated from every other cooperative bank and credit society on the platform.

This separation is enforced at the database engine level using PostgreSQL Row Level Security (RLS) — not at the application layer. Here is why that distinction matters: an application-layer check can be bypassed by a software bug. A database engine check cannot. PostgreSQL physically refuses to return Bank A's rows to a Bank B query. There is no configuration error, no code bug, no shortcut that can override this.

Not even ezPigmy engineers can access one bank's data by logging in as another bank. The database engine itself blocks it.

Not even ezPigmy engineers can access Bank A's data from a Bank B login. The database engine blocks it at the source.

---

Every Transaction Is Encrypted

Your data is protected in two situations: while it is moving across the network (in transit), and while it is sitting on the server (at rest).

In transit: All communication between the field agent's Pigmy POS device, the bank portal, and our servers uses TLS 1.2/1.3 — the same encryption standard used by internet banking portals and payment gateways. No readable data passes over the network. An attacker intercepting the traffic sees only encrypted bytes.

At rest: Data stored on our servers is encrypted using AES-256 — the same encryption standard used by banks worldwide. Even if someone physically accessed a server drive, they would find encrypted data they cannot read without the decryption keys.

Intercepting the network traffic between the POS device and the server gives an attacker encrypted bytes — nothing readable.

---

No One Gets In Without Proving Who They Are

Every login to ezPigmy requires more than a password. A stolen password alone is not enough to access your bank's data.

We use DPoP (Demonstration of Proof-of-Possession) — an advanced authentication standard that cryptographically binds each session token to the specific device that generated it. In plain English: when an agent logs in on their phone, the system creates a session key tied to that exact phone. If someone steals the agent's password and tries it on a different device, the session is rejected. The stolen password gets them nothing.

Passwords are stored as bcrypt hashes — a one-way mathematical transformation that cannot be reversed. No plain-text password is stored anywhere in the system. Even we cannot read your users' passwords.

If an agent's phone is lost or stolen, their session token is cryptographically invalid on any other device.

---

Can ezPigmy Be Hacked? Our Layered Defence

No software system is completely immune to attack. Anyone who tells you otherwise is selling something. What we can honestly say is this: our architecture is designed so that bypassing one security layer still leaves three independent layers between an attacker and your data.

Layer 1 — The gateway: Every API request from every client — web portal, Android POS device, or bank integration — passes through a central security gateway that validates the request before any backend service sees it. Unauthenticated requests are rejected here, before they go anywhere.

Layer 2 — Service isolation: Our backend services are not reachable from the internet directly. They only accept requests that arrive through the gateway, verified by a cryptographic shared secret. A direct attack on the backend is blocked before it begins.

Layer 3 — Role-based access control: Once inside, every user is limited to what their role permits. An agent account cannot access manager dashboards. A manager cannot access another bank's records. Permissions are enforced on every request, not only at login.

Layer 1 fails → Layer 2 blocks. Layer 2 fails → Layer 3 blocks. Each layer is independent.

---

Built to Support Your RBI and NABARD Compliance Obligations

ezPigmy is built specifically for urban cooperative banks, district cooperative banks, and PACS operating under RBI and NABARD frameworks. We do not claim "RBI certified" — no such formal certification programme exists for cooperative bank field collection software. What we do claim is that ezPigmy's architecture is designed to support your bank's compliance obligations.

Here is how:

• Full digital audit trail — every collection, every login, every session change, and every manager action is permanently logged with a timestamp and agent identity. RBI guidelines require regulated entities to maintain traceable audit records. ezPigmy makes this automatic.
• Least-privilege access control — agents access only their assigned collection sessions. Managers access only their bank's data. No user has more access than their role requires, consistent with RBI's access control guidance for IT systems in banks.
• Transaction receipts at every collection — printed on the spot via the handheld POS device. Your bank's record-keeping obligations are met at the point of collection, not reconstructed later.
• Indian data storage — your data stays in India, consistent with RBI's data localisation guidance for regulated entities.

Every session, every collection, every login — permanently logged and traceable for your auditor.

---

If your IT team or auditor has specific questions about our server infrastructure, security architecture, or how ezPigmy supports your compliance obligations — we will walk them through it directly. No marketing pitch.

Request a free demo → and ask us anything.