Cyber Resilience Directions for Payment System Operators

The cyber resilience directions for payment system operators require authorised non-bank PSOs to treat connected systems, data flows, APIs and vendors as part of a governed security environment. For an embedded-insurance journey, the practical task is not to assume that every insurance activity falls within the directions. It is to identify where onboarding, checkout, premium payment, servicing or claims workflows touch the PSO’s payment systems and then assign ownership, evidence and incident responsibilities for those touchpoints.

What the cyber resilience directions mean for payment system operators

The Reserve Bank of India issued the Master Directions on Cyber Resilience and Digital Payment Security Controls for non-bank Payment System Operators on November 5, 2026. They apply to all authorised non-bank PSOs. The directions took effect on November 5, 2026 for large and medium non-bank PSOs, while small non-bank PSOs must comply from April 1, 2028. RBI identifies payment aggregators, large prepaid payment instrument issuers and several other specified operators as large non-bank PSOs.

The directions place oversight of information-security risks, cyber risk and cyber resilience with the PSO’s board. They also require a board-approved information-security policy, a distinct Cyber Crisis Management Plan and responsibility for implementation to be assigned to a senior executive with relevant information-security expertise. A cyber risk assessment is required when a PSO launches a new product, service or technology, or makes a major change to an existing product, service, infrastructure or process. (rbi.org.in)

For product and partnership teams, this creates a clear starting question: Does the embedded-insurance implementation introduce a new connection, data flow, vendor dependency or material change within the payment environment? If it does, the PSO should bring the change into its established security assessment and approval process rather than treating insurance integration as an isolated commercial feature.

Which embedded-insurance journeys touch payment-security controls

An insurance journey can intersect with payment infrastructure at several points:

• A customer selects cover during merchant checkout and pays the premium within the same transaction experience.
• A fintech uses payment or onboarding data to determine which insurance option to display.
• A payment success event triggers enrolment, policy issuance or a confirmation API.
• A refund, cancellation or failed payment must be reconciled with the insurance record.
• A claims journey retrieves a transaction reference, payment status or merchant record as supporting evidence.
• A partner dashboard combines insurance status with payment, customer or merchant information.

These examples do not mean the RBI directions regulate the insurance product itself. The directions apply to the authorised non-bank PSO and cover its payment-system applications, information assets, data, infrastructure, processes and relevant third-party dependencies. They require the PSO to maintain records of key assets, critical functions and third-party providers, along with diagrams of network connections, dependencies and data flows involving third-party systems. (rbi.org.in)

A useful scoping exercise is to trace the journey from the first insurance offer to the final servicing or claim event. Mark each point at which the workflow reads, writes, transmits or derives information from a payment system. The PSO can then distinguish the payment-security boundary from the insurer’s product administration and claims responsibilities.

BharatSure’s API infrastructure for embedded insurance can support policy and member workflows, while embedded insurance programmes can place cover at moments such as onboarding, checkout or loan disbursal. The PSO should still document which calls enter its controlled environment, which party authenticates each request and which records provide an audit trail.

Map responsibility across the operator, insurer, insurance infrastructure provider and other vendors

Responsibility should be mapped by activity, system and data set, not assigned through broad labels such as “technology partner” or “insurance partner”. At minimum, the operating model should identify:

• who owns the customer-facing application and payment interface;
• who authenticates systems and authorises API requests;
• who stores payment, onboarding, policy and claims data;
• who manages access rights and privileged accounts;
• who monitors logs, anomalies and integration failures;
• who patches each application or integration component;
• who investigates a suspected compromise;
• who can suspend an API, vendor connection or customer journey;
• who preserves records for audit and post-incident analysis; and
• who communicates with the customer, insurer, PSO management and authorities.

The RBI directions require PSOs to address cyber and technology risks arising from links with unregulated entities in their digital payment ecosystem, including gateways, service providers and vendors. Subject to mutual agreement, the PSO must ensure adherence to the directions by those entities and establish a board-approved organisational policy for this purpose. (rbi.org.in)

Where an insurance infrastructure provider performs a payment or settlement-related activity on a continuing basis, the RBI Framework for Outsourcing of Payment and Settlement-related Activities may also be relevant. That framework covers payment-related outsourcing, including incidental activities such as customer onboarding and IT-based services. It states that outsourcing does not reduce the obligations of the PSO, its board or senior management, and that the PSO retains ultimate control over the outsourced activity.

This does not make every insurer, broker or claims provider an outsourced payment service provider. Teams should assess the actual function being performed. An insurer that receives a confirmed enrolment after payment may sit outside the operation of the payment system. A technology provider that processes payment-linked onboarding data, operates part of the checkout integration or maintains payment reconciliation records may create a closer payment-security dependency.

Build control evidence into onboarding, checkout and claims workflows

A control is more useful when the workflow automatically creates evidence that it operated. For each embedded-insurance integration, decide which system will retain:

• API authentication and authorisation records;
• request, response and error logs;
• timestamps and transaction identifiers;
• consent and customer-choice records;
• access grants, changes and revocations;
• deployment and change approvals;
• reconciliation results;
• incident tickets and escalation timestamps; and
• evidence of data deletion or access termination at offboarding.

The Master Directions require secure-by-design development, security controls for procured products, annual security testing at minimum, and security audits before deploying or redeploying services supporting critical functions. They also prescribe API measures addressing authentication, authorisation, confidentiality, integrity, availability and threat protection. (rbi.org.in)

Data controls should follow the information rather than stop at organisational boundaries. The directions require a data-leak-prevention policy covering business and customer information held by the PSO or at vendor-managed facilities. They also call for traceability of data assets, secure handling of personally identifiable information and encryption of data in transit, at rest, or both. (rbi.org.in)

In practice, a checkout integration should avoid passing a complete onboarding record when a smaller verified data set will perform the required function. A claims workflow should separate payment evidence from unrelated customer information. Access should be limited to the team and system components that need it for the documented purpose.

BharatSure’s claims infrastructure provides a workflow layer for claim intimation, document handling, status tracking and communication. When such a layer is connected to PSO data, teams should define which payment references can be accessed, who can retrieve them and how those actions appear in the operator’s evidence trail.

Prepare incident escalation and customer communication playbooks

The incident playbook should not begin with a generic instruction to “notify all partners”. It should specify what event occurred, which systems and data may be affected, who has authority to contain it, and which reporting clock has started.

Under the Master Directions, the PSO must maintain a board-approved incident-response mechanism covering prompt notification to senior management, relevant employees and applicable authorities. Response strategies must address different scenarios, stakeholder coordination and consistent communication. The directions also require post-incident analysis, including forensic analysis where necessary, to establish impact and root cause. (rbi.org.in)

Unusual incidents such as cyber-attacks, outages of critical systems or infrastructure, internal fraud and settlement delays must be reported to RBI in its prescribed format within six hours of detection. Cyber security incidents must also be reported to CERT-In. (rbi.org.in)

For an embedded-insurance journey, the playbook should answer four operational questions:

1. Detection: Can either partner identify anomalous API traffic, unusual data retrieval or mismatches between payment and policy records?
2. Containment: Who can disable the insurance component without unnecessarily interrupting the core payment service?
3. Assessment: Which team determines whether payment data, policy data, claims documents or customer credentials were exposed?
4. Communication: Which entity communicates about the payment incident, and which handles policy or claim servicing updates?

Customer messages should accurately identify the affected service and avoid confusing a payment outage with an insurance-coverage decision. The playbook should also cover pending enrolments, duplicate debits, failed premium records and claims that depend on temporarily unavailable payment evidence.

Vendor due diligence questions for insurance and technology partners

The following questions can support payment operator vendor risk management without assuming that every partner has the same role:

Scope and dependency

• Which payment-related activity, data set or system dependency does the partner handle?
• Is the service operationally critical to payment, enrolment, reconciliation or customer support?
• Which subcontractors, cloud providers or external APIs support the service?

Security controls

• How are application identities, credentials and privileged accounts managed?
• How are data segregated between the PSO, insurer and other clients?
• What testing is performed after source-code or configuration changes?
• How quickly can access be revoked or a compromised connection be disabled?

Incident readiness

• What events must the vendor disclose to the PSO, and within what contractual period?
• Can the vendor provide logs, technical evidence and named incident contacts without delay?
• Has the recovery process been tested jointly across the payment and insurance workflow?

Audit, continuity and exit

• Does the agreement preserve the PSO’s audit and inspection rights?
• Can the PSO retrieve relevant records during an investigation or service transition?
• Is customer and transaction data exportable, separable and capable of secure deletion?
• What happens to pending enrolments, refunds and claims if the service is unavailable or terminated?

The RBI outsourcing framework requires written agreements to define outsourced activities and performance standards, preserve access to relevant records, support continuous monitoring, address customer-data confidentiality, include continuity plans, control subcontracting and retain audit rights. It also requires at least annual review of a service provider’s financial and operational condition. (rbi.org.in)

Separately, the 2026 Master Directions require PSOs to protect their networks from vendor environments and obtain independent certified assurance of cyber-resilience capabilities from vendors involved in critical processes and activities. (rbi.org.in)

FAQ: Do the directions change how a payment operator can distribute insurance?

Do the directions introduce a new insurance-distribution permission?

No. The directions establish cyber-resilience and digital-payment-security requirements for authorised non-bank PSOs. They do not prescribe insurance-distribution permissions, insurance product structures or claims eligibility. Those questions remain separate from the PSO’s responsibility to protect its payment systems and connected information assets.

Is an insurer automatically a payment-system vendor?

No. Classification depends on the function performed. The PSO should determine whether the insurer or insurance infrastructure provider performs an outsourced payment-related activity, connects to the digital payment ecosystem, or accesses systems and data covered by the PSO’s security framework.

Can a PSO transfer payment-security accountability to an insurance technology provider?

No. For outsourced payment and settlement-related activities, the RBI framework states that the PSO retains ultimate control and that outsourcing does not reduce the obligations of the PSO, its board or senior management. The framework has applied to non-bank PSO outsourcing arrangements since March 31, 2022.

What should teams do before launching an embedded-insurance integration?

Map the end-to-end journey, identify payment-system touchpoints, classify data and dependencies, assign control owners, review vendors, test incident hand-offs and establish the records needed to demonstrate that controls operated. Keep insurance product governance distinct while documenting every interface with the PSO’s payment environment.

Book a demo to map an embedded-insurance journey to BharatSure’s white-label infrastructure, servicing and claims workflows.