Subprocessor / Service Provider Disclosure Framework

1.1 This Subprocessor / Service Provider Disclosure Framework (“Framework”) establishes the principles, contractual standards, classification rules, disclosure practices and governance requirements applicable to third-party service providers used by StampMitra in connection with the StampMitra Developer Platform, APIs, verification services, e-Stamp services, e-Sign services, document-related services, infrastructure and related services.

1.2 The purpose of this Framework is to provide transparency regarding the categories and roles of external service providers that may support StampMitra while protecting confidential commercial relationships, security-sensitive architecture, provider credentials and operational information.

1.3 This Framework forms part of the StampMitra Developer policy framework and shall be read together with the Developer Terms of Service, Developer Privacy Policy, Data Processing Addendum, Third-Party & Underlying Services Policy, API Security Policy, API SLA & Service Availability Policy and other applicable StampMitra policies.

2.1 This Framework is a published StampMitra policy.

2.2 Where incorporated into an executed agreement, Order Form, Data Processing Addendum or other binding contractual instrument, this Framework shall have contractual effect to the extent provided in that instrument.

2.3 This Framework does not by itself create a direct contractual relationship between a Developer and any external service provider engaged by StampMitra.

2.4 Nothing in this Framework grants a Developer direct rights against an external service provider unless expressly provided under applicable law or a separate written agreement.

3.1 This Framework applies to external entities engaged by StampMitra in connection with:

• (a) hosting;
• (b) cloud infrastructure;
• (c) databases;
• (d) storage;
• (e) networking;
• (f) communications;
• (g) authentication;
• (h) security;
• (i) fraud prevention;
• (j) verification;
• (k) document processing;
• (l) payment processing;
• (m) e-Stamp related processing;
• (n) e-Sign related processing;
• (o) data-source connectivity;
• (p) monitoring;
• (q) analytics;
• (r) customer support;
• (s) technical operations;
• (t) business continuity;
• (u) professional services;
• (v) compliance support; and
• (w) other functions reasonably necessary to operate the StampMitra services.

3.2 This Framework applies whether a provider is engaged directly by StampMitra or indirectly through an authorized intermediary, aggregator or service arrangement, subject to the classification principles set out below.

4.1 The legal and operational role of an external provider shall be determined by the actual nature of processing and services performed and not merely by the commercial label assigned to the provider.

4.2 A provider described commercially as a “service provider”, “vendor”, “partner”, “processor”, “aggregator” or similar term shall not automatically constitute a Subprocessor.

4.3 StampMitra shall assess the actual processing relationship, purpose, instructions, data access, contractual arrangement and applicable law when determining the provider's classification.

5.1 “StampMitra” means BANI GLOBAL INDUSTRIES LLP and the StampMitra platform and services operated by it.

5.2 “Developer” means an individual, freelancer, organization, business or other customer authorized to use StampMitra's Developer Platform or APIs.

5.3 “Personal Data” means information relating to an identified or identifiable natural person, to the extent protected under Applicable Data Protection Law.

5.4 “Processing” has the meaning assigned under applicable data protection law.

5.5 “Subprocessor” means a third party appointed by StampMitra to Process Personal Data on behalf of StampMitra in circumstances where StampMitra itself is acting as a Data Processor or equivalent role for the relevant Processing activity.

5.6 “Underlying Service Provider” means an external service provider, data source, platform, system, institution or service whose services may be used by StampMitra to fulfil, validate, process, route or complete an API transaction or service request.

5.7 “Infrastructure Provider” means a provider supplying hosting, cloud, storage, networking, computing, database or related technical infrastructure.

5.8 “Communication Provider” means a provider supporting SMS, email, messaging, notification, telecommunications or similar communications.

5.9 “Payment Service Provider” means a provider supporting payment collection, payment processing, settlement, reconciliation, payment authentication or related financial infrastructure.

5.10 “Verification or Data Source Provider” means an authorized external system, data source or service used to support identity, business, document, status, verification or other information processing.

5.11 “Security Provider” means a provider supporting security, fraud detection, threat detection, monitoring, authentication, risk analysis or related functions.

5.12 “Professional Service Provider” means a lawyer, auditor, consultant, accountant, compliance adviser, technical adviser or similar professional service provider.

5.13 “External System” means a system outside the direct operational control of StampMitra that exchanges information with StampMitra.

5.14 “Applicable Data Protection Law” means all data protection and privacy laws applicable to the relevant Processing activity, including the Digital Personal Data Protection Act, 2023 and rules made thereunder to the extent applicable and in force, as well as other applicable privacy and data protection requirements.

5.15 “Disclosure Register” means the Subprocessor / Service Provider information maintained or made available by StampMitra through an authorized channel where applicable.

6.1 StampMitra may operate as an aggregator, technology intermediary, orchestration layer and service integration platform.

6.2 A typical transaction architecture may involve: Developer Application → StampMitra Developer Platform → StampMitra API → Internal Processing / Routing / Orchestration → Authorized External System / Underlying Service Provider → StampMitra Processing → Developer Response

6.3 The above architecture is illustrative and may vary by service, jurisdiction, transaction type, technical availability, regulatory requirement or operational condition.

6.4 StampMitra may use multiple providers for the same service.

7.1 Not every Underlying Service Provider is a Subprocessor.

7.2 A provider may be an Underlying Service Provider without Processing Personal Data on StampMitra's behalf in the capacity required for classification as a Subprocessor.

7.3 A provider may instead:

• (a) independently determine purposes or means of Processing;
• (b) operate an independent regulated service;
• (c) provide an external verification result;
• (d) operate an external government or public system;
• (e) provide a payment service;
• (f) provide a communications service;
• (g) act as an independent data source;
• (h) receive information as necessary to perform an external service;
• (i) provide infrastructure;
• (j) provide professional advice; or
• (k) operate under a separate legal or regulatory framework.

7.4 The determination shall be based on actual activities and Applicable Data Protection Law.

8.1 Government departments, statutory authorities, public authorities, courts, regulators and other public bodies are not automatically Subprocessors merely because StampMitra transmits information to or receives information from them.

8.2 Such bodies may operate independent statutory, regulatory or public-service functions.

8.3 StampMitra's relationship with such bodies shall be governed by applicable law, applicable procedures and the nature of the relevant service.

9.1 StampMitra may engage providers in the following categories:

• (a) cloud and hosting providers;
• (b) storage providers;
• (c) database providers;
• (d) networking providers;
• (e) CDN and edge providers;
• (f) infrastructure monitoring providers;
• (g) security providers;
• (h) fraud prevention providers;
• (i) authentication providers;
• (j) OTP and communication providers;
• (k) email providers;
• (l) messaging providers;
• (m) payment infrastructure providers;
• (n) payment processing providers;
• (o) verification providers;
• (p) data-source providers;
• (q) document processing providers;
• (r) e-Sign service providers;
• (s) e-Stamp service providers;
• (t) identity verification providers;
• (u) analytics providers;
• (v) customer support providers;
• (w) ticketing providers;
• (x) professional advisers;
• (y) auditors;
• (z) legal and compliance advisers;
• (aa) backup and disaster recovery providers;
• (ab) observability providers; and
• (ac) other specialized service providers.

10.1 StampMitra may appoint Subprocessors where reasonably necessary to provide, secure, maintain or improve the applicable services.

10.2 Subprocessor appointment may be necessary for:

• (a) infrastructure;
• (b) storage;
• (c) communications;
• (d) security;
• (e) monitoring;
• (f) technical operations;
• (g) data processing;
• (h) support;
• (i) disaster recovery;
• (j) compliance;
• (k) service continuity; or
• (l) other legitimate operational purposes.

11.1 StampMitra shall apply commercially reasonable due diligence when selecting service providers that may have material access to Personal Data or critical service infrastructure.

11.2 Depending upon risk, due diligence may consider:

• (a) security controls;
• (b) privacy practices;
• (c) technical capability;
• (d) operational resilience;
• (e) regulatory requirements;
• (f) contractual protections;
• (g) incident history where reasonably available;
• (h) access-control practices;
• (i) data retention;
• (j) deletion capability;
• (k) geographic processing;
• (l) business continuity;
• (m) financial and operational reliability; and
• (n) service-specific risks.

11.3 The depth of due diligence may be proportionate to the nature and sensitivity of the service.

12.1 Where a provider qualifies as a Subprocessor, StampMitra shall seek appropriate contractual protections consistent with Applicable Data Protection Law and the applicable DPA.

12.2 Such contractual protections may address:

• (a) confidentiality;
• (b) lawful Processing;
• (c) purpose limitation;
• (d) data minimization;
• (e) security;
• (f) access controls;
• (g) incident management;
• (h) breach cooperation;
• (i) rights-request assistance;
• (j) retention;
• (k) deletion;
• (l) return of data;
• (m) further subcontracting;
• (n) audit or assurance;
• (o) regulatory cooperation; and
• (p) other requirements appropriate to the Processing activity.

13.1 Providers receiving confidential StampMitra information shall be subject to appropriate confidentiality obligations.

13.2 Provider personnel shall receive access only where reasonably required for their authorized functions.

13.3 Confidential information may include:

• (a) credentials;
• (b) API architecture;
• (c) provider relationships;
• (d) commercial terms;
• (e) transaction routing;
• (f) technical configurations;
• (g) security information;
• (h) pricing information;
• (i) customer information; and
• (j) non-public operational information.

14.1 StampMitra expects applicable providers to maintain security measures appropriate to the risks associated with their services.

14.2 Depending on the service, controls may include:

• (a) access management;
• (b) authentication;
• (c) least-privilege access;
• (d) network security;
• (e) encryption;
• (f) logging;
• (g) monitoring;
• (h) vulnerability management;
• (i) secure development;
• (j) backup controls;
• (k) incident response;
• (l) business continuity; and
• (m) secure deletion.

15.1 StampMitra shall seek to ensure that Processing by Subprocessors is consistent with the applicable contractual instructions and Applicable Data Protection Law.

15.2 The precise obligations applicable to each provider shall depend upon:

• (a) the provider's role;
• (b) the data involved;
• (c) the Processing activity;
• (d) applicable law;
• (e) the contractual arrangement; and
• (f) the relevant StampMitra service.

16.1 StampMitra shall seek to limit information shared with an external provider to information reasonably required for the relevant purpose.

16.2 StampMitra may transmit information where necessary to:

• (a) execute a requested transaction;
• (b) perform verification;
• (c) obtain a service result;
• (d) process payment;
• (e) deliver a document;
• (f) send a notification;
• (g) prevent fraud;
• (h) secure the platform;
• (i) comply with law; or
• (j) maintain service continuity.

17.1 Developers are responsible for ensuring that information submitted to StampMitra may lawfully be processed and transmitted for the requested purpose.

17.2 Developers shall obtain required notices, consents, authorizations or permissions from their End Users where applicable.

17.3 Developers shall not submit unnecessary Personal Data merely because an API technically permits such submission.

17.4 Developers shall comply with all applicable restrictions relating to children, sensitive information, identity documents, financial information and regulated information.

18.1 A Developer may use StampMitra APIs on behalf of its own customers, users, employees, clients or other persons.

18.2 Where a Developer submits Personal Data relating to such persons, the Developer shall remain responsible for its own lawful basis, notices, instructions and obligations to the extent required by Applicable Data Protection Law.

18.3 StampMitra may Process such information through authorized service providers as reasonably required to provide the requested service.

19.1 Some service providers may process information in locations outside India.

19.2 International Processing shall be undertaken subject to Applicable Data Protection Law and applicable contractual requirements.

19.3 Where a legally required transfer mechanism, authorization, assessment or contractual safeguard applies, StampMitra may implement such measure as appropriate to the relevant Processing activity.

19.4 StampMitra does not guarantee that every provider or every service will process data exclusively within India unless such restriction is expressly stated in the applicable commercial agreement.

20.1 Provider location may vary according to:

• (a) infrastructure architecture;
• (b) service configuration;
• (c) disaster recovery;
• (d) availability;
• (e) regulatory requirements;
• (f) provider operations;
• (g) customer configuration; and
• (h) technical routing.

20.2 Processing locations may therefore change where permitted by law and contract.

21.1 StampMitra may add, replace, remove or modify Subprocessors where reasonably necessary to operate the services.

21.2 Changes may occur due to:

• (a) technology migration;
• (b) security requirements;
• (c) business continuity;
• (d) provider performance;
• (e) service availability;
• (f) regulatory requirements;
• (g) commercial changes;
• (h) provider discontinuation;
• (i) geographic requirements; or
• (j) other legitimate operational reasons.

22.1 Where legally or contractually required, StampMitra shall provide reasonable advance notice of material Subprocessor changes through an authorized communication channel.

22.2 The notice mechanism may include:

• (a) the Developer Portal;
• (b) policy updates;
• (c) account notifications;
• (d) contractual notices;
• (e) email;
• (f) an authorized service notice; or
• (g) another commercially reasonable method.

22.3 StampMitra is not required to disclose changes that do not materially affect the relevant Processing activity where such disclosure is not required by applicable law or contract.

23.1 Where an applicable DPA or law provides a Developer with a right to object to a Subprocessor appointment, the Developer may exercise that right in accordance with the applicable contractual procedure.

23.2 Any objection should identify reasonable and specific grounds relating to data protection, privacy or security risk.

23.3 General commercial disagreement with a provider shall not, by itself, constitute a data-protection objection.

24.1 StampMitra may evaluate an objection based on:

• (a) the nature of the Processing;
• (b) the data involved;
• (c) the alleged risk;
• (d) available technical controls;
• (e) contractual safeguards;
• (f) applicable law;
• (g) available alternatives; and
• (h) operational feasibility.

24.2 StampMitra may propose reasonable alternative measures where appropriate.

25.1 A Developer does not have an unconditional right to require StampMitra to retain any particular Subprocessor.

25.2 StampMitra may replace providers where reasonably necessary to maintain service quality, security, compliance, continuity or commercial viability.

26.1 StampMitra may engage temporary or emergency providers where reasonably necessary to:

• (a) respond to a security incident;
• (b) restore service;
• (c) address infrastructure failure;
• (d) mitigate fraud;
• (e) comply with law;
• (f) address a critical vulnerability; or
• (g) maintain business continuity.

26.2 Where legally or contractually required, applicable notifications shall be made following such appointment.

27.1 StampMitra may obtain services through intermediaries, aggregators, platforms or managed-service arrangements.

27.2 Where an intermediary uses further providers, the applicable legal classification shall be determined according to the actual Processing arrangement.

27.3 StampMitra may not always have a direct contractual relationship with every entity involved in an external service chain.

28.1 Underlying Service Providers may perform functions necessary to complete a Developer-requested service.

28.2 Such providers may include external:

• (a) verification systems;
• (b) document systems;
• (c) e-Stamp systems;
• (d) e-Sign systems;
• (e) payment systems;
• (f) government-connected systems;
• (g) data sources;
• (h) regulated systems;
• (i) communication systems; and
• (j) other service infrastructure.

28.3 An Underlying Service Provider is not automatically a Subprocessor.

29.1 StampMitra may treat provider identities, commercial relationships, pricing, routing arrangements, technical interfaces and contractual terms as confidential information.

29.2 StampMitra is not required to publicly disclose commercially sensitive provider information merely because an external provider participates in service delivery, except where disclosure is required by applicable law or binding contractual obligation.

30.1 Disclosure of provider information may be restricted where such disclosure could:

• (a) compromise security;
• (b) expose credentials;
• (c) reveal sensitive architecture;
• (d) facilitate circumvention;
• (e) violate confidentiality obligations;
• (f) breach third-party contractual restrictions;
• (g) expose commercially sensitive information; or
• (h) create operational or fraud risk.

31.1 Where applicable, StampMitra may maintain a Subprocessor Disclosure Register.

31.2 The Register may contain:

• (a) provider name;
• (b) provider category;
• (c) Processing purpose;
• (d) Processing role;
• (e) data categories;
• (f) geographic Processing location;
• (g) effective date;
• (h) status;
• (i) relevant service; and
• (j) other information appropriate for transparency.

31.3 The level of information disclosed may be limited where necessary to protect confidential, security-sensitive or commercially sensitive information.

32.1 The following structure may be used for the Register:

33.1 StampMitra shall not represent an entity as a Subprocessor merely because that entity is commonly used in the technology industry.

33.2 Provider disclosures shall be based on actual commercial and operational relationships.

33.3 Where provider information has not been formally approved for publication, StampMitra may disclose the applicable provider category instead of the provider's commercial name, subject to law and contract.

34.1 Payment-related service providers may support:

• (a) payment initiation;
• (b) payment authentication;
• (c) transaction processing;
• (d) settlement;
• (e) reconciliation;
• (f) refunds;
• (g) payment status;
• (h) fraud prevention; and
• (i) related financial infrastructure.

34.2 Payment providers may operate under independent legal, regulatory and contractual obligations.

34.3 StampMitra shall not represent that every payment provider is a Subprocessor merely because payment-related information is transmitted during a transaction.

35.1 Communication providers may process information required to send:

• (a) OTPs;
• (b) transactional SMS;
• (c) email;
• (d) WhatsApp or other messaging;
• (e) service notifications;
• (f) security notifications; or
• (g) support communications.

35.2 Developers remain responsible for lawful communications and appropriate End User permissions where applicable.

36.1 Security and fraud providers may process technical, transactional or risk-related information for:

• (a) fraud detection;
• (b) abuse prevention;
• (c) threat detection;
• (d) authentication;
• (e) security monitoring;
• (f) anomaly detection; and
• (g) incident response.

36.2 Such providers may receive limited information necessary to perform their security functions.

37.1 Infrastructure providers may support:

• (a) compute;
• (b) storage;
• (c) databases;
• (d) networking;
• (e) backups;
• (f) monitoring;
• (g) content delivery;
• (h) disaster recovery; and
• (i) other infrastructure services.

37.2 Access shall be governed by applicable technical and contractual controls.

38.1 StampMitra may engage professional advisers such as:

• (a) legal advisers;
• (b) auditors;
• (c) accountants;
• (d) compliance advisers;
• (e) security advisers; and
• (f) technical consultants.

38.2 Such advisers may receive information reasonably necessary for their professional engagement and may be subject to professional confidentiality obligations.

39.1 Where StampMitra acts as a Data Processor or equivalent role, StampMitra may assist the relevant Data Fiduciary or controller in responding to Data Principal or data-subject requests to the extent required by applicable law and the applicable DPA.

39.2 Subprocessors may be required to provide reasonable assistance to StampMitra for such requests.

39.3 Assistance shall be proportionate to the nature of the Processing and applicable legal requirements.

40.1 A Subprocessor shall be expected, where contractually required, to notify StampMitra of a security incident affecting relevant Personal Data or StampMitra systems.

40.2 StampMitra may require reasonable cooperation for:

• (a) investigation;
• (b) containment;
• (c) remediation;
• (d) evidence preservation;
• (e) legal assessment;
• (f) regulatory compliance; and
• (g) affected-party communications.

41.1 StampMitra shall assess reported incidents according to:

• (a) affected data;
• (b) affected systems;
• (c) nature of compromise;
• (d) potential impact;
• (e) applicable law;
• (f) contractual requirements; and
• (g) available evidence.

41.2 Notification obligations shall be determined according to Applicable Data Protection Law and applicable contractual requirements.

41.3 This Framework does not establish a universal incident notification deadline unless separately agreed.

42.1 A provider may receive lawful requests from government, regulatory, judicial or law-enforcement authorities.

42.2 Where legally permitted, StampMitra expects providers to handle such requests in accordance with applicable law and appropriate confidentiality requirements.

42.3 StampMitra may respond directly to lawful governmental requests concerning information within its possession or control.

43.1 StampMitra may disclose provider information where required by:

• (a) court order;
• (b) statutory requirement;
• (c) regulatory direction;
• (d) law-enforcement requirement;
• (e) legal proceeding;
• (f) governmental authority; or
• (g) other legally binding process.

43.2 Disclosure shall be limited to the extent legally required where reasonably practicable.

44.1 StampMitra may use reasonable assurance mechanisms to assess provider security and compliance.

44.2 Depending upon provider risk and contractual arrangements, assurance may include:

• (a) questionnaires;
• (b) certifications where actually held;
• (c) independent audit reports;
• (d) security assessments;
• (e) contractual attestations;
• (f) technical reviews; and
• (g) other reasonable evidence.

44.3 StampMitra does not represent that every provider possesses a particular certification unless expressly stated.

45.1 Where an applicable DPA provides audit or assurance rights, such rights shall be exercised subject to reasonable limitations.

45.2 StampMitra may satisfy reasonable assurance requirements through:

• (a) questionnaires;
• (b) summaries;
• (c) available reports;
• (d) certifications;
• (e) contractual information;
• (f) controlled assessments; or
• (g) other appropriate evidence.

45.3 Direct unrestricted audits of StampMitra's providers are not automatically available to Developers.

46.1 A Developer shall not receive direct credentials, endpoints, administrative access or other privileged access to an Underlying Service Provider merely because StampMitra uses that provider.

46.2 StampMitra controls its own integration architecture.

47.1 Unless expressly agreed otherwise, a Developer does not enter into a direct contract with an Underlying Service Provider merely by using StampMitra.

47.2 StampMitra's agreements with providers remain separate commercial relationships.

48.1 StampMitra may change the provider used for a particular service where reasonably necessary.

48.2 Provider substitution may occur without Developer approval where permitted by applicable agreement and law.

48.3 Substitution may occur due to:

• (a) outage;
• (b) performance;
• (c) security;
• (d) pricing;
• (e) regulatory requirements;
• (f) geographic requirements;
• (g) availability;
• (h) discontinuation; or
• (i) business continuity.

49.1 StampMitra may dynamically route requests between authorized providers.

49.2 Routing decisions may consider:

• (a) availability;
• (b) capacity;
• (c) service type;
• (d) jurisdiction;
• (e) transaction requirements;
• (f) security;
• (g) latency;
• (h) cost;
• (i) regulatory conditions; and
• (j) operational resilience.

49.3 Developers shall not assume that identical requests are always processed by the same external provider.

50.1 An external provider may discontinue, materially change or restrict a service.

50.2 StampMitra may respond by:

• (a) replacing the provider;
• (b) modifying routing;
• (c) modifying the API;
• (d) suspending affected functionality;
• (e) migrating to another service; or
• (f) discontinuing the affected service.

51.1 Certain services may be subject to third-party terms, conditions, acceptable-use rules, privacy requirements or regulatory conditions.

51.2 Where such terms are applicable to a Developer or End User, StampMitra may require compliance with relevant pass-through requirements.

51.3 StampMitra shall not be responsible for terms that a Developer independently accepts with a third party.

52.1 Certain services may be subject to statutory, regulatory or jurisdiction-specific requirements.

52.2 StampMitra may therefore impose additional requirements for services involving:

• (a) identity;
• (b) e-Stamp;
• (c) e-Sign;
• (d) verification;
• (e) payments;
• (f) government systems;
• (g) financial information;
• (h) legal documents; or
• (i) other regulated activities.

53.1 Availability of an external service may vary by:

• (a) State;
• (b) Union Territory;
• (c) jurisdiction;
• (d) government authority;
• (e) document type;
• (f) transaction type;
• (g) regulatory status; or
• (h) provider coverage.

53.2 StampMitra does not guarantee uniform provider availability across all jurisdictions.

54.1 External providers may supply data, status information, verification results or transaction information.

54.2 StampMitra may normalize, format, transform or relay such information.

54.3 StampMitra does not guarantee that information originating from an independent external source is always complete, current or error-free.

55.1 Where a government authority, regulated entity, external data source or other independent system makes a decision, StampMitra does not control that decision.

55.2 StampMitra may communicate the status or result returned by such system, subject to applicable technical limitations.

56.1 Use of external government-connected systems does not mean that StampMitra is itself a government department, statutory authority or government agency.

56.2 Unless expressly stated, StampMitra does not represent that it has governmental ownership, endorsement or affiliation.

57.1 Providers may retain information according to:

• (a) applicable law;
• (b) contractual obligations;
• (c) legitimate operational requirements;
• (d) security requirements;
• (e) backup requirements; and
• (f) their applicable retention schedules.

57.2 StampMitra shall seek appropriate contractual deletion or retention controls for Subprocessors where required.

58.1 Where applicable, StampMitra may require Subprocessors to delete or return Personal Data after completion of the relevant service or termination of the Processing relationship.

58.2 Deletion may be subject to:

• (a) legal retention;
• (b) backup cycles;
• (c) security records;
• (d) dispute preservation;
• (e) regulatory requirements; or
• (f) other lawful retention requirements.

59.1 Data contained in backups may remain temporarily after primary deletion.

59.2 Backup retention and deletion shall be managed according to applicable technical and contractual controls.

59.3 Data restored from backup shall remain subject to applicable security and access controls.

60.1 Provider access to StampMitra systems shall be limited to authorized personnel and functions to the extent reasonably practicable.

60.2 Privileged access may be subject to additional controls, including:

• (a) authentication;
• (b) least privilege;
• (c) logging;
• (d) approval;
• (e) access review; and
• (f) credential management.

61.1 StampMitra shall not intentionally provide Developers with private credentials belonging to its external providers.

61.2 Provider credentials may be protected through technical and organizational controls.

61.3 Developers shall not attempt to discover, extract or circumvent provider credentials.

62.1 Developers shall not use StampMitra APIs to:

• (a) discover confidential upstream provider identities;
• (b) enumerate private provider endpoints;
• (c) identify hidden routing infrastructure;
• (d) bypass StampMitra;
• (e) obtain upstream credentials; or
• (f) establish unauthorized direct access.

62.2 Security research shall remain subject to the applicable Security Vulnerability Disclosure Policy.

63.1 A Developer shall not use StampMitra to identify and circumvent StampMitra's commercial relationship with an external provider.

63.2 This includes attempts to:

• (a) bypass StampMitra;
• (b) obtain provider credentials;
• (c) access private APIs;
• (d) reverse engineer confidential routing;
• (e) replicate restricted provider access; or
• (f) interfere with StampMitra's provider relationship.

64.1 StampMitra may independently negotiate pricing, commercial terms and service arrangements with external providers.

64.2 Developer pricing does not necessarily equal StampMitra's cost of obtaining an external service.

64.3 StampMitra may include technology, orchestration, support, compliance, operational and other charges in its commercial pricing.

65.1 External provider pricing or commercial conditions may change.

65.2 Where such changes materially affect StampMitra services, StampMitra may modify applicable commercial terms subject to the Developer Terms, Order Form or applicable agreement.

66.1 External service failures do not automatically create a right to refund.

66.2 Refund eligibility shall be determined under the applicable Billing, API Credits & Refund Policy, Service Terms, Order Form or other applicable commercial agreement.

66.3 Where a transaction is governed by an external provider's rules, applicable pass-through conditions may also apply.

67.1 StampMitra may use idempotency, reconciliation and transaction controls to reduce duplicate processing.

67.2 External provider systems may independently assign transaction identifiers and statuses.

67.3 Developers shall not assume that a network timeout means that a transaction failed.

68.1 A transaction may be:

• (a) initiated;
• (b) accepted;
• (c) processing;
• (d) pending;
• (e) completed;
• (f) failed;
• (g) rejected;
• (h) cancelled;
• (i) expired; or
• (j) otherwise classified by the applicable service.

68.2 Provider status and StampMitra status may differ temporarily while reconciliation occurs.

69.1 An external provider outage may affect StampMitra service availability.

69.2 StampMitra may:

• (a) retry;
• (b) queue;
• (c) route to another provider;
• (d) degrade functionality;
• (e) suspend affected transactions;
• (f) display a pending status; or
• (g) take other reasonable operational measures.

70.1 If StampMitra becomes aware of a security incident involving an external provider that materially affects StampMitra or Developer Data, StampMitra may take appropriate measures, including:

• (a) restricting traffic;
• (b) disabling an integration;
• (c) rotating credentials;
• (d) changing routing;
• (e) suspending affected services;
• (f) investigating impact; and
• (g) providing notifications where required.

71.1 StampMitra may maintain multiple providers or alternative technical arrangements where commercially and technically appropriate.

71.2 Such arrangements are intended to improve resilience but do not constitute an absolute guarantee of uninterrupted service.

72.1 StampMitra may assess provider performance based on:

• (a) availability;
• (b) latency;
• (c) error rates;
• (d) security;
• (e) support;
• (f) compliance;
• (g) capacity;
• (h) transaction success; and
• (i) other service criteria.

73.1 StampMitra may change provider routing or service architecture to improve service quality.

73.2 Provider substitution does not necessarily require a change to the Developer-facing API.

74.1 A Subprocessor shall be expected to restrict personnel access to Personal Data according to legitimate business need.

74.2 Personnel with relevant access may be subject to confidentiality obligations and appropriate security controls.

75.1 A Subprocessor shall not appoint further subprocessors in a manner inconsistent with applicable contractual requirements.

75.2 Where applicable, further subprocessors shall be subject to appropriate data protection and security obligations.

76.1 StampMitra may apply different controls based on provider risk.

76.2 Risk factors may include:

• (a) volume of data;
• (b) sensitivity;
• (c) access privileges;
• (d) service criticality;
• (e) geographic exposure;
• (f) regulatory status;
• (g) external connectivity;
• (h) security impact; and
• (i) operational dependency.

77.1 Providers handling high-risk information or critical infrastructure may be subject to enhanced review.

77.2 Enhanced review may include additional:

• (a) security questionnaires;
• (b) contractual controls;
• (c) access restrictions;
• (d) monitoring;
• (e) assurance evidence; and
• (f) incident requirements.

78.1 Developers shall not submit children's Personal Data unless lawful and expressly permitted under the relevant service.

78.2 Where children's data is legitimately processed, StampMitra may impose additional controls or restrictions.

78.3 Providers may be required to comply with additional requirements applicable to such data.

79.1 Developers shall minimize submission of sensitive or highly confidential information.

79.2 Where a service necessarily requires such information, additional security, contractual or legal requirements may apply.

80.1 Identity documents may be processed for services where legitimately required.

80.2 Developers shall submit only the information necessary for the requested transaction.

80.3 StampMitra may transmit such documents to authorized external systems where required to provide the relevant service.

81.1 e-Stamp-related transactions may require interaction with external systems or authorized service providers.

81.2 Processing may depend upon jurisdiction, document type, stamp article, denomination, purchaser details, payment and other applicable requirements.

81.3 External provider or authority requirements may affect the availability and completion of such transactions.

82.1 e-Sign transactions may involve external identity, authentication, signing or certificate infrastructure.

82.2 StampMitra may transmit information necessary to complete the requested signing transaction.

82.3 Applicable legal and technical requirements may vary by signing service.

83.1 Verification requests may involve authorized data sources or external systems.

83.2 Results may depend on the accuracy, availability and authorization of the relevant external source.

84.1 External provider integrations shall be subject to appropriate API security measures.

84.2 Depending upon the integration, controls may include:

• (a) authenticated communication;
• (b) credential protection;
• (c) access restrictions;
• (d) request validation;
• (e) logging;
• (f) timeout controls;
• (g) retry controls;
• (h) response validation; and
• (i) monitoring.

85.1 External systems may communicate with StampMitra through callbacks or webhooks.

85.2 StampMitra may validate, authenticate, retry, record or otherwise process such communications according to applicable technical controls.

86.1 StampMitra may monitor provider integrations for:

• (a) availability;
• (b) errors;
• (c) unusual activity;
• (d) security events;
• (e) latency;
• (f) transaction failures; and
• (g) operational anomalies.

87.1 Provider-related activity may be logged where reasonably necessary for:

• (a) security;
• (b) troubleshooting;
• (c) audit;
• (d) reconciliation;
• (e) fraud prevention;
• (f) compliance; and
• (g) service operation.

87.2 Logs shall be subject to applicable retention and access controls.

88.1 StampMitra may transform data before transmission to an external provider where reasonably required.

88.2 Transformation may include:

• (a) formatting;
• (b) normalization;
• (c) field mapping;
• (d) validation;
• (e) identifier mapping; and
• (f) protocol conversion.

89.1 StampMitra may normalize external provider errors before returning them to Developers.

89.2 Provider-specific internal information may be omitted from Developer-facing responses where necessary for:

• (a) security;
• (b) confidentiality;
• (c) abstraction;
• (d) contractual compliance; or
• (e) operational protection.

90.1 StampMitra does not guarantee that API responses will identify the external provider used for a transaction.

90.2 Provider identities may be intentionally abstracted.

91.1 Developer documentation may describe service behavior without disclosing confidential upstream architecture.

91.2 Documentation may use generic terms such as:

• (a) Authorized Service Provider;
• (b) Underlying Service Provider;
• (c) External Service;
• (d) Verification Source;
• (e) Data Source; or
• (f) External System.

92.1 Inclusion of a provider in StampMitra's service architecture does not constitute an endorsement of that provider by the Developer.

92.2 References, where legally required or otherwise published, shall not imply partnership, agency or joint venture unless expressly stated.

93.1 StampMitra and its external providers are independent entities unless expressly stated otherwise.

93.2 No provision of this Framework creates:

• (a) agency;
• (b) partnership;
• (c) employment;
• (d) joint venture; or
• (e) fiduciary relationship

between StampMitra and an external provider merely because the provider supports StampMitra services.

94.1 Developers using StampMitra for regulated, financial, governmental, legal or other high-risk workflows should conduct their own due diligence appropriate to their use case.

94.2 StampMitra's use of a provider does not replace the Developer's independent compliance obligations.

95.1 Enterprise customers may receive additional information regarding relevant service-provider arrangements where contractually appropriate.

95.2 Additional disclosure may be subject to:

• (a) confidentiality;
• (b) security;
• (c) provider restrictions;
• (d) commercial sensitivity; and
• (e) applicable law.

96.1 Enterprise or regulated customers may be required to execute a confidentiality agreement before receiving certain provider information.

96.2 StampMitra may refuse disclosure where disclosure would violate binding confidentiality obligations or create material security risk, subject to applicable law.

97.1 StampMitra shall not disclose:

• (a) private credentials;
• (b) private keys;
• (c) security tokens;
• (d) internal administrative endpoints;
• (e) sensitive network architecture;
• (f) confidential routing information; or
• (g) other information that could materially compromise security.

98.1 Provider pricing, discounts, commercial terms, rebates, margins, contractual commitments and negotiation history may constitute confidential information.

98.2 Such information shall not be disclosed merely because a provider supports the StampMitra service.

99.1 The following general matrix applies subject to actual processing:

99.2 The actual role shall be determined by the specific Processing activity and applicable law.

100.1 Where the StampMitra Data Processing Addendum applies, this Framework supplements the DPA.

100.2 In case of conflict concerning Processing of Personal Data, the DPA shall prevail to the extent of that conflict, unless a later executed agreement expressly provides otherwise.

101.1 The StampMitra Developer Privacy Policy governs StampMitra's privacy practices for information covered by that policy.

101.2 This Framework provides additional transparency regarding external providers and does not replace the Privacy Policy.

102.1 The StampMitra Third-Party & Underlying Services Policy governs the broader relationship between Developers, StampMitra and external service dependencies.

102.2 This Framework provides more specific governance for Subprocessors and service-provider disclosure.

103.1 External provider security is also governed by applicable requirements in the StampMitra API Security Policy.

103.2 Nothing in this Framework limits StampMitra's security obligations under an applicable contract.

104.1 External providers may affect API availability, latency or transaction completion.

104.2 Availability commitments, if any, shall be governed by the applicable SLA or executed commercial agreement.

105.1 Use of multiple external providers does not create an absolute guarantee of uninterrupted service.

105.2 External infrastructure may experience:

• (a) outages;
• (b) maintenance;
• (c) capacity constraints;
• (d) regulatory restrictions;
• (e) technical failure;
• (f) cyber incidents; or
• (g) other interruptions.

106.1 Changes in law, regulation, government systems or industry requirements may require StampMitra to change or replace providers.

106.2 Such changes may occur without the Developer's prior approval where permitted by applicable agreement and law.

107.1 Where applicable law requires data localization or restricted transfer, StampMitra may modify provider arrangements to satisfy such requirements.

107.2 StampMitra does not represent that every service is subject to identical localization requirements.

108.1 StampMitra may terminate a provider relationship where reasonably necessary.

108.2 Provider termination may be caused by:

• (a) breach;
• (b) security concerns;
• (c) service failure;
• (d) regulatory requirements;
• (e) insolvency;
• (f) discontinuation;
• (g) commercial reasons; or
• (h) strategic changes.

109.1 Where reasonably practicable, StampMitra may implement replacement arrangements before terminating a critical provider.

109.2 Emergency situations may require immediate replacement, restriction or suspension.

110.1 Migration between providers may involve technical changes.

110.2 StampMitra may implement migration in phases to reduce service disruption.

110.3 Developers may be required to modify integrations where the migration materially changes the Developer-facing interface.

111.1 StampMitra may abstract provider changes from Developers.

111.2 Where provider changes require API changes, such changes shall be managed under the applicable API Versioning, Suspension & Deprecation Policy.

112.1 StampMitra does not guarantee that a particular external provider will remain available indefinitely.

112.2 Provider selection may change over the lifecycle of a service.

113.1 A Subprocessor may be removed from the Disclosure Register when:

• (a) its engagement ends;
• (b) the relevant Processing ends;
• (c) the provider is replaced;
• (d) the provider becomes unnecessary; or
• (e) the provider otherwise ceases to qualify as an applicable Subprocessor.

114.1 StampMitra shall seek to keep any published Subprocessor Register reasonably accurate.

114.2 Publication status may depend on:

• (a) contractual requirements;
• (b) provider confidentiality;
• (c) legal requirements;
• (d) operational updates; and
• (e) verification of the underlying relationship.

115.1 Each disclosed provider may have an effective date or equivalent record indicating when its relevant engagement became applicable.

115.2 Historical providers may not remain listed indefinitely after their engagement ends unless required for transparency or recordkeeping.

116.1 StampMitra may maintain historical provider records for contractual, legal, audit, security or compliance purposes.

116.2 Historical records may not necessarily be publicly available.

117.1 Inclusion of a provider in a Disclosure Register does not constitute a warranty regarding:

• (a) uninterrupted availability;
• (b) error-free operation;
• (c) regulatory outcome;
• (d) transaction success;
• (e) data accuracy; or
• (f) fitness for a particular purpose.

118.1 Nothing in this Framework grants an external provider third-party beneficiary rights under the Developer's agreement with StampMitra.

118.2 Similarly, publication of provider information does not create contractual rights against such provider.

119.1 StampMitra's liability relating to external service providers shall be governed by the applicable Developer Terms, DPA, Order Form or other executed agreement.

119.2 Nothing in this Framework independently creates a separate liability regime.

120.1 Any indemnification obligations shall be governed by the applicable Developer Terms, DPA, Order Form or other executed agreement.

120.2 This Framework does not independently expand or reduce those obligations unless expressly stated.

121.1 External provider failures may constitute events outside StampMitra's reasonable control depending on the circumstances.

121.2 Force majeure treatment shall be determined under the applicable agreement.

122.1 StampMitra may share limited information with security, fraud-prevention or verification providers where reasonably necessary to detect or prevent:

• (a) fraud;
• (b) identity abuse;
• (c) credential compromise;
• (d) transaction abuse;
• (e) document manipulation;
• (f) payment abuse; or
• (g) other unlawful or harmful activity.

123.1 Provider integrations may be used to identify and prevent:

• (a) automated abuse;
• (b) API enumeration;
• (c) credential attacks;
• (d) transaction manipulation;
• (e) excessive traffic;
• (f) account takeover; and
• (g) other prohibited conduct.

124.1 Providers may process information contained in legal or business documents where necessary to provide the requested service.

124.2 Developers remain responsible for ensuring that such processing is authorized and lawful.

125.1 StampMitra may use automated systems, including machine learning or AI-assisted tools, where reasonably necessary for security, fraud prevention, support, operations or other lawful purposes.

125.2 Such use remains subject to applicable privacy, security and contractual requirements.

125.3 StampMitra shall not represent that every provider uses AI unless expressly stated.

126.1 StampMitra may use analytics or observability providers to understand service performance and usage.

126.2 Analytics data shall be handled according to applicable privacy and security requirements.

127.1 StampMitra may use third-party support or communications systems.

127.2 Support providers may receive information reasonably necessary to resolve a support request.

128.1 Developers shall not submit passwords, API secret keys, private credentials or other unnecessary secrets in support requests.

128.2 StampMitra may redact or restrict such information.

129.1 Developers may contact StampMitra through the authorized legal or support channel regarding provider-related questions.

129.2 StampMitra may respond at an appropriate level of detail subject to:

• (a) confidentiality;
• (b) security;
• (c) legal requirements;
• (d) provider contracts; and
• (e) commercial sensitivity.

130.1 StampMitra may cooperate with regulators and lawful authorities concerning provider arrangements.

130.2 Such cooperation may include disclosure of provider information where legally required.

131.1 StampMitra may update this Framework to reflect:

• (a) legal changes;
• (b) provider changes;
• (c) technology changes;
• (d) security requirements;
• (e) service changes;
• (f) regulatory developments; or
• (g) operational improvements.

131.2 Material updates shall be communicated in accordance with the applicable contractual requirements.

132.1 An update to this Framework shall not retroactively modify rights or obligations already accrued under an executed agreement unless legally permitted and expressly agreed where required.

133.1 In case of conflict:

• (a) applicable mandatory law shall prevail;
• (b) an executed enterprise agreement or Order Form shall prevail to the extent expressly inconsistent;
• (c) the applicable DPA shall govern Personal Data Processing matters;
• (d) the Developer Terms shall govern general contractual matters;
• (e) this Framework shall govern Subprocessor and provider disclosure matters;
• (f) other StampMitra policies shall apply according to their respective subject matter.

134.1 If any provision is held invalid or unenforceable, the remaining provisions shall remain effective to the extent permitted by law.

135.1 Failure to enforce any provision shall not constitute a permanent waiver unless expressly agreed in writing.

136.1 This Framework shall be governed by the laws of India, subject to applicable mandatory statutory provisions.

136.2 Dispute resolution shall be governed by the dispute resolution provisions of the applicable Developer Terms, DPA, Order Form or other executed agreement.

137.1 Legal notices and provider-disclosure questions may be directed to:

Legal Team

BANI GLOBAL INDUSTRIES LLP

[email protected]

138.1 StampMitra may intentionally use generic provider descriptions in public documentation where naming a provider could increase security, fraud, circumvention or operational risk.

138.2 Generic descriptions may include:

• “Authorized Underlying Service Provider”
• “External Service Provider”
• “Authorized Verification Source”
• “External Data Source”
• “Payment Service Provider”
• “Communication Service Provider”
• “Cloud Infrastructure Provider”
• “Security Service Provider”

139.1 Where StampMitra is required to provide specific provider information, such information may be supplied through:

• (a) the Developer Portal;
• (b) an applicable DPA;
• (c) an enterprise agreement;
• (d) a security questionnaire;
• (e) a confidentiality-protected disclosure;
• (f) an authorized legal communication; or
• (g) another authorized channel.

140.1 StampMitra is not required to publicly publish every vendor, supplier, service provider, subcontractor, technology component or external system used in its operations.

140.2 Public disclosure shall be limited to information that StampMitra determines is appropriate or legally required.

141.1 StampMitra may periodically review whether an external provider continues to qualify as a Subprocessor.

141.2 A provider's classification may change following:

• (a) service changes;
• (b) data-flow changes;
• (c) contractual changes;
• (d) legal changes;
• (e) architectural changes; or
• (f) changes in Processing purpose.

142.1 A provider initially classified as an Underlying Service Provider may later qualify as a Subprocessor if its actual Processing relationship changes.

142.2 Conversely, a provider may cease to qualify as a Subprocessor when the relevant Processing relationship ends or changes.

143.1 The mere fact that an external provider receives Personal Data does not automatically establish that it is a Subprocessor.

143.2 Actual purpose, control, instructions, legal obligations and Processing activities shall be considered.

144.1 An external provider may independently determine purposes and means of Processing in accordance with its own legal or regulatory obligations.

144.2 In such circumstances, the provider may not be a Subprocessor for that Processing activity.

145.1 Professional advisers may independently determine how they perform their regulated or professional functions.

145.2 Their Processing role shall therefore be determined by the actual legal relationship and applicable law.

146.1 StampMitra may maintain records of material Subprocessor appointments and changes for governance and compliance purposes.

146.2 Such records may include:

• (a) provider identity;
• (b) service;
• (c) approval;
• (d) effective date;
• (e) contractual status;
• (f) risk assessment; and
• (g) termination date.

147.1 StampMitra may require internal approval before onboarding a provider that materially affects:

• (a) Personal Data;
• (b) security;
• (c) financial transactions;
• (d) e-Stamp services;
• (e) e-Sign services;
• (f) verification;
• (g) critical infrastructure; or
• (h) regulatory compliance.

148.1 Provider offboarding may include:

• (a) access revocation;
• (b) credential rotation;
• (c) data return;
• (d) data deletion;
• (e) integration removal;
• (f) monitoring removal;
• (g) documentation updates; and
• (h) contractual closure.

149.1 Where appropriate, provider credentials may be rotated after provider termination or material security events.

149.2 Rotation requirements depend upon the nature of the integration and associated risk.

150.1 StampMitra may require providers to cooperate in investigating security incidents affecting StampMitra services.

150.2 Cooperation may include:

• (a) technical information;
• (b) logs;
• (c) incident timelines;
• (d) affected-service information;
• (e) remediation information; and
• (f) other reasonably necessary evidence.

151.1 Provider forensic information may be confidential, privileged or security-sensitive.

151.2 StampMitra may restrict disclosure of such information subject to legal and contractual requirements.

152.1 Developers shall not represent themselves as authorized representatives of StampMitra when communicating with an external provider.

152.2 Developers shall not use StampMitra's name to obtain unauthorized provider access or information.

153.1 Developers shall not impersonate StampMitra, its personnel, its service providers or other authorized entities for the purpose of obtaining confidential information or access.

154.1 Security research concerning provider integrations shall be conducted only within the authorization boundaries of the StampMitra Security Vulnerability Disclosure Policy.

154.2 Testing third-party systems without authorization is not permitted merely because those systems are connected to StampMitra.

155.1 StampMitra authorization to test StampMitra APIs does not automatically authorize testing of:

• (a) provider infrastructure;
• (b) government systems;
• (c) payment infrastructure;
• (d) external data sources;
• (e) external websites; or
• (f) other third-party systems.

156.1 Vulnerabilities discovered in external providers may be handled according to the applicable security disclosure process.

156.2 StampMitra may coordinate disclosure without revealing confidential provider information to the Developer.

157.1 Additional provider requirements may apply to specific services.

157.2 Such requirements may be communicated through:

• (a) API documentation;
• (b) service terms;
• (c) technical specifications;
• (d) Order Forms;
• (e) developer notices; or
• (f) other authorized channels.

158.1 An Enterprise customer may receive a service-provider schedule where expressly agreed.

158.2 Such schedule may include additional information subject to confidentiality and security restrictions.

159.1 Enterprise disclosure does not necessarily include:

• (a) provider pricing;
• (b) provider contracts;
• (c) credentials;
• (d) private architecture;
• (e) internal security controls;
• (f) unrelated providers; or
• (g) commercially sensitive information.

160.1 A Developer may request information concerning relevant Processing locations where such information is required by an applicable agreement or law.

160.2 StampMitra may provide location information at an appropriate level of granularity.

161.1 StampMitra may consider provider certifications or independent assurance reports where available.

161.2 StampMitra shall not represent that a provider holds a specific certification unless the relevant certification has been verified and is applicable to the relevant service.

162.1 Inclusion of a provider in this Framework does not mean that StampMitra certifies the provider as universally secure or compliant with every legal framework.

163.1 StampMitra may maintain provider records for:

• (a) compliance;
• (b) legal;
• (c) security;
• (d) audit;
• (e) procurement;
• (f) operational;
• (g) contractual; and
• (h) business-continuity purposes.

164.1 Provider records may be retained for the period reasonably necessary for their purpose, subject to applicable law and internal retention requirements.

165.1 StampMitra may designate appropriate internal functions to oversee provider governance, including legal, security, technology, compliance, procurement and operations functions.

166.1 High-risk providers may be reviewed by multiple internal functions before approval.

166.2 The precise review process may vary according to provider risk and service criticality.

167.1 A material change may include:

• (a) change of Processing purpose;
• (b) material change in data categories;
• (c) change in Processing location;
• (d) significant security change;
• (e) material subcontracting change;
• (f) change in legal role; or
• (g) replacement of a critical provider.

168.1 Material provider changes shall be managed according to applicable contractual, privacy, security and operational requirements.

169.1 StampMitra may immediately restrict or replace a provider where necessary to protect:

• (a) Developer Data;
• (b) End User data;
• (c) credentials;
• (d) payment information;
• (e) StampMitra systems; or
• (f) service integrity.

170.1 This Framework shall be interpreted consistently with Applicable Data Protection Law and the StampMitra contractual framework.

170.2 Where a mandatory legal requirement conflicts with this Framework, the mandatory legal requirement shall prevail.

171.1 By using the StampMitra Developer Platform or applicable services, the Developer acknowledges that StampMitra may use authorized external service providers and Subprocessors as reasonably necessary to provide, secure, operate and maintain the services.

171.2 The Developer further acknowledges that:

• (a) not every external provider is a Subprocessor;
• (b) provider roles depend on actual Processing activities;
• (c) provider identities may be confidential;
• (d) provider arrangements may change;
• (e) external services may affect availability;
• (f) Developers remain responsible for lawful submission of data;
• (g) direct upstream access is not granted by default; and
• (h) applicable contractual and privacy obligations continue to govern the relevant Processing.

• Policy Name: StampMitra Subprocessor / Service Provider Disclosure Framework
• Policy Number: 17 of 19
• Version: 1.0
• Effective Date: 05 October 2026
• Last Updated: 05 October 2026
• Operator: BANI GLOBAL INDUSTRIES LLP
• LLPIN: ACI6373
• Legal Contact: [email protected]
• Prepared By: Legal Team, BANI GLOBAL INDUSTRIES LLP
• Status: FINAL — PUBLISHED POLICY