Third-Party & Underlying Services Policy

1.1 This Third-Party & Underlying Services Policy (“Policy”) governs the relationship between the StampMitra Developer Platform and third-party, external and underlying services used in connection with StampMitra APIs.

1.2 StampMitra operates a technology platform that may integrate, orchestrate, route, aggregate or otherwise coordinate services supplied by multiple external parties.

1.3 The Developer may therefore receive a StampMitra API response even where the underlying processing involves one or more external systems.

1.4 The purpose of this Policy is to establish:

• the nature of StampMitra's role;
• the Developer's obligations;
• the treatment of third-party dependencies;
• provider confidentiality;
• external-system limitations;
• data transmission;
• service availability;
• provider changes;
• upstream failures;
• third-party terms;
• liability allocation;
• compliance requirements.

2.1 StampMitra may operate as an intermediary technology, orchestration and service-access platform between Developers and external service infrastructure.

2.2 A simplified conceptual architecture may be:

Developer Application → StampMitra Developer Platform → StampMitra API Layer → Internal Processing / Routing / Orchestration → Authorized Underlying Service Provider(s) / Data Source(s) / External System(s) → StampMitra Processing Layer → Developer Application

2.3 This architecture is illustrative and does not constitute a disclosure of StampMitra's confidential technical architecture.

2.4 The actual routing path may vary according to:

• API;
• jurisdiction;
• service;
• transaction type;
• availability;
• capacity;
• technical requirements;
• regulatory requirements;
• commercial arrangements;
• security controls.

For this Policy:

3.1 “Third-Party Service”

Means a service supplied by a person or entity other than StampMitra.

3.2 “Underlying Service Provider”

Means an external provider, authorized data source, technology provider, service network, regulated entity, government-connected system, infrastructure provider or other third party used in connection with a StampMitra Service.

3.3 “External System”

Means a system not exclusively controlled by StampMitra.

3.4 “Upstream Service”

Means a service or functionality obtained from an external source and incorporated into or used to deliver a StampMitra Service.

3.5 “Provider Information”

Means information concerning the identity, architecture, commercial relationship, pricing, credentials, routing, contracts or technical arrangements of an Underlying Service Provider.

3.6 “Pass-Through Requirement”

Means a requirement imposed by an external service or provider that must be followed by the Developer to enable the relevant Service.

4.1 StampMitra may use multiple Underlying Service Providers.

4.2 The Developer acknowledges that StampMitra is not required to publicly identify every provider involved in delivering a Service.

4.3 Specific provider identities may constitute:

• confidential commercial information;
• trade secrets;
• contractual information;
• security-sensitive information;
• proprietary architecture.

4.4 StampMitra may therefore refer generically to:

• “Underlying Service Providers”;
• “Authorized Service Providers”;
• “External Service Providers”;
• “Third-Party Service Providers”;
• “Authorized Data Sources”;
• “External Systems”.

4.5 Such terminology does not mean that StampMitra is concealing a legally required disclosure.

5.1 The Developer shall treat non-public provider information obtained through StampMitra as Confidential Information.

5.2 The Developer shall not attempt to discover confidential provider relationships through:

• reverse engineering;
• traffic analysis;
• undocumented endpoint discovery;
• response fingerprinting;
• technical probing;
• infrastructure reconnaissance;
• credential manipulation;
• other unauthorized methods.

6.1 The Developer has no automatic right to receive:

• wholesale pricing;
• provider invoices;
• provider contracts;
• commercial margins;
• provider commissions;
• internal routing rules;
• negotiated service terms;
• provider credentials.

6.2 StampMitra's commercial relationship with an Underlying Service Provider is separate from the Developer's commercial relationship with StampMitra.

7.1 Unless expressly agreed otherwise, a Developer's use of a StampMitra API does not create a direct contractual relationship between the Developer and an Underlying Service Provider.

7.2 The Developer's contractual relationship for the relevant API is ordinarily with StampMitra.

7.3 An Underlying Service Provider may have its own legal terms that apply to the underlying service where expressly communicated or legally required.

8.1 StampMitra may determine how a request is processed.

8.2 StampMitra may:

• route requests;
• select an available provider;
• change routing;
• retry requests;
• fail over;
• transform technical formats;
• normalize responses;
• aggregate information;
• validate responses;
• apply business rules.

8.3 The Developer does not ordinarily control the internal provider-selection process.

9.1 StampMitra may dynamically select an appropriate underlying service.

9.2 Routing may change without prior Developer notice where reasonably required for:

• availability;
• capacity;
• security;
• performance;
• regulatory compliance;
• commercial continuity;
• technical compatibility.

9.3 A change in routing does not necessarily constitute a material change to the API contract if the externally documented API behavior remains substantially consistent.

10.1 StampMitra may replace an Underlying Service Provider.

10.2 Provider substitution may occur because of:

• provider discontinuation;
• technical migration;
• commercial changes;
• performance;
• security;
• compliance;
• capacity;
• service quality;
• business continuity.

10.3 StampMitra will seek to maintain API-level continuity where reasonably practicable.

Certain StampMitra APIs may depend upon external systems.

Accordingly, a Service may be affected by:

• third-party downtime;
• provider maintenance;
• government-system downtime;
• telecommunications failures;
• infrastructure failures;
• external API changes;
• external capacity restrictions;
• regulatory restrictions.

12.1 StampMitra does not control every external system used to deliver Services.

12.2 StampMitra therefore does not guarantee uninterrupted availability of an external dependency.

12.3 Applicable SLA commitments, if any, are governed by the relevant SLA and commercial terms.

External systems may produce:

• errors;
• timeouts;
• incomplete responses;
• delayed responses;
• inconsistent responses;
• temporary unavailability;
• changed response structures.

StampMitra may normalize or communicate such conditions through its API.

14.1 StampMitra may abstract underlying systems behind a standardized API.

14.2 The Developer should integrate against StampMitra's published API contract rather than attempting to depend upon undocumented upstream behavior.

14.3 An upstream provider's technical implementation is not necessarily part of the Developer-facing API specification.

The availability of a particular upstream capability does not guarantee that StampMitra will expose every underlying feature.

StampMitra may selectively expose functionality based on:

• product design;
• security;
• legal requirements;
• commercial arrangements;
• technical compatibility.

16.1 Where required to perform a Service, StampMitra may transmit relevant information to an Underlying Service Provider.

16.2 Such transmission shall be subject to:

• applicable law;
• the Developer's authorized Service request;
• applicable contractual requirements;
• security controls.

16.3 Developers should not submit information that is unnecessary for the requested Service.

By requesting a Service that requires an external provider, the Developer authorizes StampMitra, subject to applicable law and the relevant contractual arrangement, to transmit information reasonably necessary to perform that Service.

StampMitra may seek to limit information transmitted to an Underlying Service Provider to what is reasonably necessary for the relevant transaction.

However, the exact data requirements may be determined by the underlying Service.

An Underlying Service Provider may require:

• identity information;
• transaction information;
• document information;
• contact information;
• business information;
• authentication information;
• other information necessary for the requested Service.

The Developer is responsible for ensuring that the underlying request is lawful and authorized.

Where an external provider independently determines the purposes and means of its own processing, it may have a separate legal role under applicable data-protection law.

StampMitra does not represent that every external provider is a Subprocessor.

The legal classification of an external provider depends upon the actual arrangement.

An external provider may be:

• a Subprocessor;
• an independent Data Fiduciary;
• a service provider;
• an authorized data source;
• a regulated entity;
• another legally recognized category.

Processing involving external providers shall be managed consistently with applicable data-protection law and, where applicable:

• the StampMitra Privacy Policy;
• Data Processing Addendum;
• Service-Specific Terms;
• applicable contractual safeguards.

The Developer shall ensure that:

• it has authority to submit data;
• required notices have been provided;
• required consent has been obtained where applicable;
• the requested Service is lawful;
• information supplied is accurate where required.

24.1 Certain Services may be subject to additional terms imposed by an external provider or applicable regulatory framework.

24.2 Where such terms materially affect Developer use, StampMitra may communicate the relevant requirements.

24.3 The Developer must comply with applicable requirements communicated as a condition of using the Service.

An external provider may impose requirements concerning:

• data format;
• transaction limits;
• permitted uses;
• identity requirements;
• document requirements;
• geographic availability;
• authentication;
• service timing;
• transaction restrictions.

Developers must comply with such requirements where communicated by StampMitra.

Certain Services may depend upon:

• government systems;
• authorized government-connected infrastructure;
• regulated service networks;
• statutory systems;
• state-specific infrastructure.

Availability and processing may therefore be subject to governmental or regulatory conditions.

e-Stamp and related services may vary by:

• State;
• Union Territory;
• jurisdiction;
• article/instrument;
• stamp duty requirements;
• Sub-Registrar jurisdiction;
• local rules;
• government system availability.

Developers must not assume that one jurisdiction's workflow applies universally.

Where e-Stamp processing depends on external systems, StampMitra may be unable to independently control:

• government availability;
• inventory;
• transaction acceptance;
• duty calculations determined externally;
• issuance timing;
• cancellation/refund procedures.

e-Sign functionality may depend upon:

• identity verification;
• authentication;
• external signing infrastructure;
• service availability;
• regulatory requirements;
• technical requirements.

Verification results may depend upon:

• source-data availability;
• source accuracy;
• matching rules;
• source-system uptime;
• data freshness;
• external validation processes.

StampMitra cannot guarantee information that it does not independently control.

Where information originates from an external source, StampMitra may communicate the result received from that source, subject to applicable processing and normalization.

StampMitra does not necessarily independently certify every underlying data point.

StampMitra may normalize external responses to provide consistent Developer-facing formats.

Normalization may include:

• field mapping;
• status mapping;
• error mapping;
• data formatting;
• response standardization.

Normalization does not necessarily mean that StampMitra modifies the authoritative underlying record.

The Developer should distinguish between:

• the API response;
• the authoritative source record;
• StampMitra's processing status.

If an external provider becomes unavailable, StampMitra may:

• return an error;
• return a temporary unavailable status;
• retry;
• fail over;
• queue a request;
• delay processing;
• temporarily disable the affected API.

StampMitra may retry certain requests where technically and commercially appropriate.

Retries may be subject to:

• idempotency;
• provider limitations;
• transaction type;
• service rules.

Where multiple service paths are available, StampMitra may implement failover.

Failover is not guaranteed for every API.

Underlying providers may perform maintenance that affects StampMitra Services.

StampMitra may communicate material known maintenance where reasonably practicable.

An Underlying Service Provider may change:

• endpoints;
• schemas;
• authentication;
• rate limits;
• response structures;
• business rules;
• availability.

StampMitra may modify its integration to preserve Developer-facing compatibility where reasonably possible.

Where an upstream change materially affects the Developer-facing Service, StampMitra may:

• update Documentation;
• notify Developers;
• modify functionality;
• introduce a new API version;
• suspend affected functionality;
• provide an alternative where available.

If an Underlying Service Provider discontinues a Service, StampMitra may:

• migrate to another provider;
• modify the Service;
• suspend the Service;
• discontinue the affected API.

StampMitra does not guarantee that any particular Underlying Service Provider will remain part of its service architecture for any fixed period unless expressly agreed in writing.

Information regarding:

• provider routing;
• provider selection;
• provider pricing;
• provider credentials;
• provider contracts;
• internal service topology;
• upstream capacity;
• provider-specific technical details

may constitute StampMitra Confidential Information.

The Developer must not use StampMitra APIs to intentionally discover confidential upstream providers through:

• endpoint probing;
• reverse engineering;
• response fingerprinting;
• infrastructure scanning;
• error manipulation;
• unauthorized testing.

StampMitra shall not be required to provide Developers with credentials belonging to an Underlying Service Provider.

A Developer does not automatically obtain:

• provider rights;
• provider pricing;
• provider support;
• provider guarantees;
• provider contractual protections

merely because StampMitra uses the provider.

StampMitra's pricing to Developers may differ from StampMitra's costs, fees or commercial arrangements with Underlying Service Providers.

The Developer shall not assume that StampMitra's charges are a direct pass-through of upstream pricing unless expressly stated.

StampMitra may charge:

• platform fees;
• subscription fees;
• processing fees;
• API usage fees;
• service fees;
• transaction fees;
• other applicable commercial charges.

The existence of an underlying provider does not restrict StampMitra's ability to establish its own commercial model.

Changes in external provider pricing may require StampMitra to modify:

• API pricing;
• transaction fees;
• service availability;
• commercial terms.

Where contractually required, applicable notice shall be provided.

Where a third-party cost has already been incurred, refund eligibility may depend upon:

• whether the transaction completed;
• provider rules;
• service-specific terms;
• StampMitra's refund policy;
• applicable law.

An external provider failure does not necessarily mean that a transaction is automatically refundable.

The transaction status must be determined based on:

• API response;
• provider status;
• transaction records;
• applicable refund rules.

Developers should avoid submitting duplicate requests where an external service may charge or process each request independently.

Certain external transactions may become irreversible after processing.

Developers must review applicable Service-specific documentation before initiating transactions.

Cancellation may depend upon:

• Service type;
• transaction stage;
• external provider rules;
• applicable government rules;
• technical feasibility.

StampMitra cannot guarantee cancellation after an external transaction has become final.

Where an issue originates entirely within an external service, StampMitra may need to coordinate with the relevant provider before resolving the Developer's issue.

The Developer may be asked for:

• transaction ID;
• request ID;
• timestamps;
• documents;
• relevant API responses.

StampMitra may remain the Developer's primary support interface even where the underlying issue must be resolved by an external provider.

StampMitra may omit specific provider identity from support communications where disclosure is not necessary to resolve the issue and provider identity is confidential.

Additional limitations may apply to individual Services.

Examples include:

• jurisdiction;
• volume;
• transaction value;
• document size;
• identity requirements;
• processing hours;
• government availability.

The availability of a Service in one location does not guarantee availability in every:

• State;
• district;
• jurisdiction;
• country;
• Sub-Registrar office;
• government system.

StampMitra may restrict a Service based on:

• applicable law;
• provider availability;
• regulatory requirements;
• geographic limitations;
• operational constraints.

Changes in law or regulatory direction may require StampMitra or an Underlying Service Provider to:

• change workflows;
• restrict access;
• modify data requirements;
• suspend functionality;
• discontinue a Service.

StampMitra shall not be responsible for external-service failures caused by events beyond reasonable control, subject to applicable law and contractual obligations.

StampMitra may apply security controls to connections with Underlying Service Providers, including:

• authentication;
• encryption;
• access restrictions;
• credential management;
• monitoring;
• logging.

If an Underlying Service Provider experiences a security incident affecting a StampMitra Service, StampMitra may:

• investigate;
• restrict traffic;
• suspend the affected Service;
• rotate credentials;
• implement alternative routing;
• notify affected Developers where required.

Where an external provider suffers a data breach affecting Developer Data, StampMitra shall take reasonable steps appropriate to its legal and contractual role.

This may include:

• obtaining information;
• assessing impact;
• coordinating containment;
• assisting with notifications;
• implementing alternative controls.

StampMitra cannot guarantee the internal security, availability or processing practices of every external system outside its direct control.

StampMitra's obligations remain governed by its own contractual and legal responsibilities.

Developers should evaluate whether the relevant StampMitra Service is appropriate for their intended use case, particularly where:

• highly sensitive data is involved;
• regulated decisions are involved;
• critical transactions are involved;
• legal consequences depend on the result.

Where a claim arises solely from an external provider's independent conduct, responsibility shall be allocated according to:

• applicable law;
• contractual arrangements;
• actual control over the relevant processing;
• the applicable Service terms.

Unless expressly stated, StampMitra does not provide an independent warranty concerning the internal services of an Underlying Service Provider.

The use of a third-party service does not necessarily constitute:

• endorsement;
• certification;
• partnership;
• ownership;
• agency.

A Developer shall not represent an Underlying Service Provider as its own partner, agent or representative merely because StampMitra uses that provider.

StampMitra may determine how it describes its service architecture publicly, subject to mandatory disclosure obligations.

Nothing in this Policy permits StampMitra to withhold information where disclosure is legally mandatory.

Where disclosure is required, StampMitra may provide the information in the legally required manner.

Where a Developer receives confidential information regarding StampMitra's external providers, the Developer shall:

• protect it;
• limit access;
• use it only for the relevant contractual purpose;
• not publish it;
• not exploit it commercially without authorization.

The Developer shall not intentionally use confidential provider information obtained through StampMitra to bypass StampMitra's contractual relationships.

This provision does not restrict lawful independent activity based solely on public information.

A Developer may request general information regarding:

• categories of external providers;
• nature of dependencies;
• data-processing arrangements;
• relevant security controls;

where reasonably necessary for compliance or due diligence.

StampMitra may satisfy such requests through generalized or categorized information without disclosing confidential commercial identities.

Enterprise Developers may receive additional information under a separate confidentiality arrangement where commercially and legally appropriate.

Such information may include:

• security summaries;
• compliance documentation;
• data-flow information;
• provider categories;
• processing locations.

StampMitra may require an NDA before providing non-public information concerning:

• architecture;
• provider relationships;
• security;
• commercial arrangements.

Where a legally or contractually required provider/subprocessor list is maintained, StampMitra may publish or make available the relevant categories or names according to its applicable disclosure obligations.

Such a list does not necessarily disclose every commercial or technical relationship.

Not every Underlying Service Provider shall be considered a Subprocessor.

The classification depends on:

• processing purpose;
• control;
• contractual role;
• applicable law.

Where StampMitra acts as a Data Processor, the DPA governs applicable processing obligations.

This Policy does not replace the DPA.

StampMitra's Developer Privacy Policy governs processing for which StampMitra independently determines the purpose and means.

Security requirements for Developers and StampMitra shall be addressed in the API Security Policy.

Developers must comply with the API Acceptable Use Policy when interacting with external services through StampMitra.

Availability commitments relating to StampMitra Services shall be governed by the applicable SLA.

Third-party availability is subject to the limitations described in this Policy and the SLA.

If an Underlying Service Provider discontinues a required capability, StampMitra may invoke its API lifecycle and deprecation procedures.

StampMitra will seek reasonable API-level continuity but does not guarantee that every upstream functionality can be preserved indefinitely.

StampMitra may maintain:

• alternate providers;
• redundant infrastructure;
• backup systems;
• fallback mechanisms;
• alternate processing paths

where commercially and technically appropriate.

Failover may not be available for:

• every API;
• every jurisdiction;
• every transaction;
• every external provider.

StampMitra may communicate external-service incidents through:

• status pages;
• developer notifications;
• API responses;
• support channels;
• service notices.

StampMitra may distinguish between:

• StampMitra-generated errors;
• upstream errors;
• network errors;
• validation errors;
• authorization errors;
• temporary availability errors.

Developers should implement robust handling for:

• timeouts;
• retries;
• temporary failures;
• upstream unavailability;
• partial results;
• asynchronous processing.

Where external systems are involved, response times may vary.

Any contractual response-time commitment shall be governed by the applicable SLA or commercial agreement.

StampMitra may temporarily restrict an API due to scheduled or emergency maintenance by an external dependency.

During provider migration, StampMitra may:

• temporarily reduce capacity;
• change routing;
• introduce temporary limitations;
• modify internal infrastructure.

Where API behavior materially changes, applicable versioning procedures may apply.

StampMitra may attempt to preserve backward compatibility when replacing an Underlying Service Provider.

Compatibility cannot be guaranteed where external changes make equivalent functionality technically or legally impossible.

An upstream data-format change may require StampMitra to:

• map fields;
• remove unsupported fields;
• change validation;
• modify responses.

Material Developer-facing changes shall be addressed under applicable API lifecycle procedures.

Where a Service incorporates third-party software or licensed functionality, Developers may be subject to applicable license restrictions communicated by StampMitra.

StampMitra may use open-source software in its infrastructure.

Applicable open-source licenses govern the relevant components where legally applicable.

Developers shall not use StampMitra APIs to infringe third-party intellectual-property rights.

Confidential information relating to external providers may constitute trade secrets or commercially sensitive information.

Developers shall not misuse or disclose such information.

A Developer shall not use unauthorized technical access to StampMitra systems to obtain confidential information for competitive intelligence.

Public or private benchmarking of StampMitra or external service performance must comply with applicable authorization requirements and must not involve prohibited load or security testing.

Where an Underlying Service Provider raises a legitimate concern regarding a Developer's use, StampMitra may:

• investigate;
• request information;
• restrict the relevant Service;
• require remediation;
• suspend access where necessary.

StampMitra may communicate provider-specific requirements to Developers where necessary.

Such requirements may become conditions of continued access to the affected Service.

StampMitra may immediately restrict a Service if an external provider:

• withdraws authorization;
• identifies material abuse;
• experiences a security incident;
• becomes legally unavailable;
• requires emergency suspension.

If an external provider terminates a critical dependency, StampMitra may terminate or suspend the affected API where no reasonable alternative exists.

StampMitra may attempt to identify an alternative provider but does not guarantee that an equivalent alternative will exist.

Developers should maintain appropriate application-level handling for Service interruption.

For business-critical applications, Developers should not rely on a single API request path without appropriate error and fallback handling.

Where an external service processes a transaction asynchronously, the Developer should rely on the documented status mechanism rather than assuming that a timeout means failure.

Developers are responsible for implementing idempotency and transaction reconciliation where supported.

StampMitra shall not necessarily be liable for duplicate requests caused by Developer implementation.

Where a Service involves an external payment system, payment status may depend upon external confirmation.

Developers should rely on the documented transaction status rather than solely on browser redirects or client-side indications.

Refunds involving external providers may require reconciliation with the relevant external transaction.

Developers must not falsely attribute an external provider's action, failure or decision to StampMitra where the distinction is material.

Developers must accurately describe StampMitra-powered Services to their End Users.

They must not claim that StampMitra guarantees an outcome that depends upon an external authority or provider.

Where a government authority or authorized external system makes a decision, the Developer must not represent that decision as being made by StampMitra unless expressly stated.

A verification result must not automatically be represented as:

• a government certification;
• legal advice;
• absolute proof;
• permanent validation.

The precise meaning of the result depends upon the Service.

StampMitra cannot guarantee that every external authority will accept a document unless such acceptance is expressly represented.

Additional disclaimers may apply to:

• verification;
• e-Stamp;
• e-Sign;
• government-related services;
• document services.

Liability concerning an external service shall be determined by:

• the Developer Terms;
• applicable SLA;
• Service-Specific Terms;
• DPA where relevant;
• actual control over the relevant event;
• mandatory applicable law.

StampMitra does not automatically assume unlimited liability for failures occurring exclusively within an independent external system outside StampMitra's reasonable control.

Nothing in this Policy excludes liability or statutory rights that cannot lawfully be excluded.

StampMitra may update this Policy to reflect:

• provider changes;
• technical changes;
• regulatory changes;
• security developments;
• new Services;
• commercial changes.

Where required, material changes may be communicated through:

• Developer Platform;
• email;
• Documentation;
• service notifications;
• updated policy publication.

The updated version shall specify its effective date.

Continued use after the effective date may constitute acceptance where legally permissible and appropriate.

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

This Policy shall be governed by the laws of India, subject to mandatory applicable law.

Disputes shall be handled in accordance with the dispute-resolution provisions contained in the StampMitra Developer Terms of Service or applicable written commercial agreement.

For legal, contractual or third-party service matters:

• Legal Team
• BANI GLOBAL INDUSTRIES LLP
• LLPIN: ACI6373

Registered Office: 2-A/3, Kundan Mansion, Asaf Ali Road, Turkman Gate, Central Delhi, NCT of Delhi, India – 110002

Email: [email protected]

By using a StampMitra API, the Developer acknowledges that:

• 1. StampMitra may rely on external service infrastructure;
• 2. specific upstream providers may remain confidential;
• 3. external service availability is not entirely controlled by StampMitra;
• 4. provider routing may change;
• 5. external data may have limitations;
• 6. external transaction rules may apply;
• 7. Developers must comply with communicated provider requirements;
• 8. Developers must not attempt to circumvent StampMitra's upstream relationships;
• 9. StampMitra may substitute or discontinue external dependencies where necessary; and
• 10. the Developer remains responsible for lawful use of the Services.

• Policy: StampMitra Third-Party & Underlying Services Policy
• Document Type: Developer Platform Third-Party & Service Dependency Policy
• Version: 1.0
• Status: FINAL — PUBLISHED POLICY
• Effective Date: 05 October 2026
• Last Updated: 05 October 2026

• Legal Entity: BANI GLOBAL INDUSTRIES LLP
• LLPIN: ACI6373

Registered Office: 2-A/3, Kundan Mansion, Asaf Ali Road, Turkman Gate, Central Delhi, NCT of Delhi, India – 110002

Developer Platform: developer.stampmitra.in

Legal Contact: [email protected]

• Prepared by: Legal Team
• BANI GLOBAL INDUSTRIES LLP
• [email protected]

© 2026 BANI GLOBAL INDUSTRIES LLP. All rights reserved.