Your Agents Shouldn't Be Your Security Problem — And Neither Should Your Infrastructure

Over the past few years, we have spoken to dozens of cooperative banks and banking software companies across India. Almost every one of them arrived at cooperative banking collection infrastructure the same way: someone built an Android app, connected it to the core banking system, and got agents collecting in the field. It worked. Members got receipts. Deposits came in.

Security came later. It always comes later.

That is not a criticism. It is how almost every product gets built — features first, because features create visible value. Security is invisible until it fails, so it waits.

In most industries, this timeline is acceptable. In banking collection infrastructure, "later" can mean a member data breach, an RBI audit observation, or a field agent's phone that walked out the door carrying six months of collection records — with no way to stop it.

We built ezPigmy the same way in our early days. We understand exactly how this happens.

---

What "Full Collection Infrastructure" Actually Means

When a bank or a banking software company decides to build collection infrastructure, the surface looks manageable: an Android app, a backend API, a database.

The actual scope is a different matter entirely.

Here is what production-ready, compliant collection infrastructure requires — each item is a separate engineering and regulatory problem:

UPI switch — NPCI membership or sub-membership, payment settlement flows, automated reconciliation, dispute resolution, transaction limits, and 24/7 uptime obligations.

NCMC card switch — National Common Mobility Card certification, offline prepaid card transaction support for rural areas with intermittent connectivity, and card lifecycle management. A separate certification track from UPI entirely.

RuPay switch — Domestic card network integration, PCI-DSS compliance scope, transaction routing, and a certification process that typically takes six to twelve months.

Managed Android device — A Mobile Device Management stack, application lockdown policies, OS-level enforcement preventing agents from installing unauthorised apps, and remote wipe capability that works when the device reconnects after being offline.

Device-level security — Cryptographic session binding so that a stolen password cannot be used from a different device, secure storage for session keys, and biometric authentication tied to the specific managed terminal.

Encrypted transactions — TLS 1.3 for data in transit, AES-256 for data at rest, and a key management system that rotates and protects encryption keys without exposing them.

SMS alert infrastructure — DLT registration with TRAI, message template approval, sender ID registration, delivery tracking, and fallback routing when the primary route fails.

WhatsApp Business API — A Business Solution Provider partnership, message template approval from Meta, delivery receipt handling, and opt-out management.

Full audit trail — Tamper-proof, device-timestamped logs per session and per transaction — exportable in a format that regulators and auditors can read and verify.

A realistic estimate for a capable team building this from scratch: six to eight engineers, eighteen to twenty-four months, before any of it is production-hardened and certifiable.

---

Security Is the Last Thing Anyone Thinks About (Until It Isn't)

Security is almost always the last layer added to any product. Not because teams are careless — because it is invisible until it fails, and a failing feature is always more urgent than an invisible risk.

In banking collection software, three things make deferred security particularly costly:

Member financial data. A breach does not affect an abstract user account. It affects a member's pigmy savings balance, their loan repayment history, their deposit record. Real people, real money, real harm.

Field agents operate away from the office. The attack surface for a collection app is not your server room — it is every device in every village your agents visit. An office network has firewalls and IT oversight. A personal phone at a customer's doorstep has whatever apps the agent installed last week.

Regulators are watching more closely. RBI's Master Circular on IT governance for Urban Cooperative Banks expects banks to demonstrate control over every device that accesses member data. "The agent uses their personal phone" is not a satisfying answer when an auditor asks what device controls are in place.

We have written in detail about the specific, documented attack vectors — malware reading transaction files, clipboard hijack attacks stealing OTPs, fake app overlays capturing credentials, lost phones with no remote wipe. If you have not read it: Why Your Agent's Personal Phone Is a Security Risk for Your Bank.

Security retrofitted onto existing architecture always costs more and protects less than security designed in from the start. The teams that avoid a painful audit observation are the ones that did not wait for the forcing event.

---

In the Age of AI, Anyone Can Build a Scam App

A few years ago, building a convincing fake banking app required a skilled developer — weeks of work, specific knowledge, real effort. That barrier is gone.

Today, AI coding tools can generate a working Android APK from a plain-text description in a matter of hours. A non-technical person can describe what they want — "an app that looks like a pigmy collection app, captures the login credentials, and sends them to a server" — and receive functional code. No programming background required.

This changes the risk profile for every bank that runs collection software on agents' personal phones. It is no longer sufficient to trust that building a credible malicious app is difficult. It is not.

Here are the specific scam types that become possible when collection software runs on an unmanaged personal phone:

1. Fake collection app overlay — An app that renders a screen identical to the real collection app on top of it. When the agent enters their login credentials, the fake app captures and forwards them before passing control to the real app. The agent sees nothing unusual.

2. AI-cloned UPI payment screen — A fake UPI transaction UI that shows a successful payment confirmation to the member while routing the actual payment to an attacker's VPA. The receipt looks real. The money goes elsewhere.

3. Silent data harvesting APK — Requests "read storage" permission, which many agents grant without reading. Quietly reads the collection app's local transaction history, member names, phone numbers, and account details. Uploads everything to a remote server. No visible behaviour.

4. Clipboard OTP interceptor — Monitors the clipboard continuously. When an OTP arrives via SMS and the agent copies it, the interceptor captures it and forwards it to an attacker within seconds — before the agent can use it.

5. WhatsApp impersonation bot — Uses the agent's WhatsApp session (which is on the same personal phone) to send members messages that appear to come from the agent, requesting payments to a new account number.

6. Fake passbook display — Shows inflated savings balances to members while recording lower deposit amounts in the real system. The discrepancy surfaces weeks later in an audit, with no clear chain of evidence.

7. Session token theft — Extracts a live authenticated session token from the collection app's local storage and replays it from a remote device. With a DPoP-unprotected session, this gives complete account access without the agent's knowledge.

None of these attacks are theoretical. All of them exploit the same root condition: a personal phone that runs multiple apps from multiple sources, with no organisational control over what is installed.

On a locked-down managed collection terminal, none of these attack surfaces exist. There is only one application on the device. It cannot be replaced, overlaid, or supplemented. The file system is not readable by any other process. There is no clipboard to hijack because there is no WhatsApp, no browser, no second app of any kind.

The question for every bank is not whether these attacks will be attempted. The question is whether the device your agents use gives those attacks a surface to land on.

---

What ezPigmy Stack's API Gives You Instead

ezPigmy Stack is the infrastructure layer that cooperative banks and banking software providers can integrate with — instead of building and certifying each piece themselves. Here is what is already running in production:

UPI Switch

NPCI-certified UPI collection. Agents collect at the doorstep via QR code or push-pay. Settlement, reconciliation, and dispute handling are managed at the infrastructure level. Your application calls an API; the switch handles the rest.

NCMC Card Switch

National Common Mobility Card transactions processed through ezPigmy Stack's certified switch. Supports offline prepaid card collection for rural agents operating with intermittent connectivity. No separate NCMC certification required on your end.

RuPay Switch

Domestic RuPay card acceptance through a standard REST API. PCI-DSS compliance scope sits with the platform. Your integration is a single authenticated API call.

Managed Android Device

A purpose-built collection terminal locked to the collection application. No Play Store, no personal app installation, no WhatsApp. MDM is administered at the platform level. Banks have remote wipe, session revocation, and device audit available from the management console.

Encrypted Transactions

Every transaction travels over TLS 1.3. Data at rest is AES-256. Session tokens are cryptographically bound to the issuing device using DPoP — a stolen password is not enough to open a session on a different device. More on how this works →

SMS Alerts

DLT-registered infrastructure with template management and delivery tracking. Members receive confirmation at the point of collection. No separate telecom vendor relationship required.

WhatsApp Notifications

WhatsApp Business API connected notification pipeline. Collection confirmations, payment receipts, and passbook updates delivered to members on WhatsApp. Template approval and BSP partnership are managed by ezPigmy Stack.

Full Audit Trail

Every login, every transaction, every session event logged with device identifier, agent identity, and server-verified timestamp. Regulator-ready. Exportable on demand.

---

Build vs. Integrate: The Honest Comparison

Both paths are real options. The question is what your team's time is worth over the next two years — and whether you want to find any gaps in your security architecture before or after a regulator does.

---

To Banking Software Providers: The API Path Is Better for Your Customers and for You

If you are building collection software for cooperative banks, this section is for you.

When your application runs on an agent's personal phone, the security posture of that deployment was determined the day the phone left the factory — not by your team, not by the bank. It was shaped by everything the agent has installed since, every permission they have granted, and whether anyone can reach that device if it goes missing.

This is a structural limitation of deploying on unmanaged hardware. It is not a reflection on your product.

The concern is about where the risk lands. When a bank gets an audit observation about agent device controls, the conversation turns to the software they are using and what that software provided. A bank that cannot demonstrate device management, session controls, and an audit trail has a harder conversation with the regulator — regardless of how good the rest of their systems are.

An API integration with ezPigmy Stack changes this. Your product remains yours — your interface, your workflow, your relationship with the bank. The device, the payment switches, the encryption layer, and the compliance architecture are provided by the platform. Your bank customers get managed, certified, auditable infrastructure from day one, through your product.

This is not about replacing what you have built. It is about giving your customers a stronger foundation — and removing a category of risk that does not need to sit with either of you.

If you are interested in how an integration could work alongside your existing product, we are open to that conversation.

---

Want to see the full stack running for your bank? Book a free demo →

Building collection software for banks and want to explore API integration? Let's talk →