Developer Grievance Redressal Policy

1.1 This Developer Grievance Redressal Policy (“Policy”) establishes the framework through which Developers may submit, track, escalate, and seek resolution of grievances, complaints, disputes, service concerns, privacy concerns, security concerns, billing disputes, and other issues relating to StampMitra Developer Services.

1.2 The objective of this Policy is to provide a structured, transparent, accessible, and reasonably efficient grievance-handling mechanism.

1.3 This Policy is intended to operate alongside the StampMitra Developer Terms of Service and other applicable Developer Policies.

1.4 Nothing in this Policy limits any statutory right, regulatory remedy, judicial remedy, contractual right, or other remedy available to a person under applicable law.

2.1 This Policy applies to Developers using the StampMitra Developer Platform, APIs, Sandbox, Production Services, documentation, billing systems, technical support, and related Developer Services.

2.2 It may also apply to authorised representatives of Developers where they are acting on behalf of the relevant Developer.

2.3 This Policy does not replace specialised procedures for security vulnerabilities, personal-data rights, payment disputes, or legal notices where a separate procedure applies.

3.1 This Policy forms part of the StampMitra Developer Policy Framework.

3.2 The Developer Terms of Service remain the principal contractual agreement governing the Developer relationship.

3.3 Where a specific policy contains a specialised complaint or escalation mechanism, that mechanism should be used for the relevant issue.

3.4 Nothing in this Policy constitutes an admission of liability by StampMitra.

4.1 “Complaint” means an expression of dissatisfaction concerning a StampMitra Service, process, decision, transaction, support interaction, billing matter, or other Developer-related matter.

4.2 “Grievance” means a Complaint requiring formal review or redressal.

4.3 “Developer” means an individual, freelancer, organisation, business, institution, or other eligible person or entity using StampMitra Developer Services.

4.4 “Grievance Officer” means the person or function designated by BANI GLOBAL INDUSTRIES LLP to handle applicable grievances.

4.5 “Support Request” means a routine request for technical, operational, documentation, or account assistance.

4.6 “Security Incident” means an actual or suspected event affecting confidentiality, integrity, availability, authentication, credentials, or security of a system or data.

4.7 “Data Protection Request” means a request relating to personal-data rights or processing under applicable privacy and data-protection law.

4.8 “Business Day” means a day other than a day on which the applicable office or authority is legally closed, subject to applicable law.

4.9 “Final Response” means the written response issued after reasonable review of a grievance.

5.1 StampMitra will seek to handle grievances in accordance with the following principles:

• (a) accessibility;
• (b) fairness;
• (c) confidentiality;
• (d) reasonable diligence;
• (e) non-retaliation;
• (f) proportionality;
• (g) accurate recordkeeping;
• (h) applicable law; and
• (i) reasonable communication.

6.1 Developers may submit grievances through the applicable official StampMitra support or legal communication channels.

6.2 Legal and policy-related grievances may be directed to:

[email protected]

6.3 Where StampMitra provides an online support portal, Developers should use the portal for routine operational matters.

7.1 Developers should first use ordinary technical support for routine matters such as:

• (a) API implementation questions;
• (b) documentation clarification;
• (c) account configuration;
• (d) Sandbox issues;
• (e) webhook configuration;
• (f) non-urgent technical errors; or
• (g) general operational assistance.

7.2 A matter may be escalated as a grievance where routine support has not adequately resolved a material concern or where the nature of the issue warrants formal review.

8.1 Grievances may include:

• (a) account access concerns;
• (b) API access decisions;
• (c) Production approval concerns;
• (d) service quality concerns;
• (e) billing disputes;
• (f) refund concerns;
• (g) transaction discrepancies;
• (h) privacy concerns;
• (i) data-processing concerns;
• (j) security concerns;
• (k) suspension or restriction concerns;
• (l) documentation concerns;
• (m) service availability concerns;
• (n) contractual concerns;
• (o) suspected misuse;
• (p) discriminatory or abusive conduct by support personnel; or
• (q) other material concerns relating to StampMitra Services.

9.1 Suspected security vulnerabilities should be submitted through the dedicated Security Vulnerability Disclosure Policy and applicable security reporting channel.

9.2 Developers should not disclose security vulnerabilities publicly before StampMitra has had a reasonable opportunity to investigate.

9.3 Security matters may receive specialised handling and may not follow ordinary grievance procedures.

10.1 Privacy and personal-data grievances should identify the relevant data-processing activity where reasonably possible.

10.2 Where a Data Processing Addendum or Developer Privacy Policy provides a specific procedure, that procedure shall apply.

10.3 StampMitra may require reasonable information to verify the identity and authority of a person submitting a data-related request.

11.1 Billing disputes should be raised through the applicable billing or support channel.

11.2 The Billing, API Credits & Refund Policy governs applicable billing, refund, credit, chargeback, and payment matters.

11.3 A billing grievance does not automatically suspend payment obligations unless otherwise agreed or required by law.

12.1 Service availability concerns should identify:

• (a) affected API;
• (b) environment;
• (c) approximate time;
• (d) relevant request or transaction identifier;
• (e) error information; and
• (f) material business impact, where relevant.

12.2 The API SLA & Service Availability Policy governs applicable availability and service-level matters.

13.1 Transaction-related grievances should include the relevant transaction identifier.

13.2 Developers should provide sufficient information to permit reconciliation.

13.3 StampMitra may distinguish between:

• (a) payment status;
• (b) API status;
• (c) external processing status;
• (d) issuance status;
• (e) signature status; and
• (f) final transaction status.

14.1 Account-related grievances may concern:

• (a) access;
• (b) verification;
• (c) account restrictions;
• (d) Production approval;
• (e) credential issues;
• (f) workspace access;
• (g) project access; or
• (h) account termination.

15.1 A Developer may request review of a suspension or restriction where a review mechanism is available.

15.2 The request should identify:

• (a) account or project;
• (b) relevant restriction;
• (c) remediation undertaken;
• (d) supporting information; and
• (e) requested resolution.

16.1 A Developer may raise a contractual concern regarding account termination through the applicable legal or support channel.

16.2 Termination review does not automatically restore account access.

17.1 A grievance may be submitted by:

• (a) the Developer;
• (b) an authorised account administrator;
• (c) an authorised representative; or
• (d) a person otherwise legally entitled to submit the grievance.

18.1 StampMitra may verify the identity and authority of a person submitting a grievance.

18.2 Where a representative submits a grievance on behalf of an organisation, StampMitra may request evidence of authority.

19.1 Anonymous complaints may be considered where sufficient information is provided.

19.2 StampMitra may be unable to provide a response where the identity or contact information of the complainant is unavailable.

20.1 Developers are encouraged to report genuine concerns in good faith.

20.2 StampMitra will not knowingly retaliate against a Developer solely for submitting a genuine grievance.

21.1 Developers must not knowingly submit false, fraudulent, malicious, threatening, repetitive, or abusive complaints.

21.2 Repeated abusive conduct may result in restrictions under applicable policies.

22.1 A grievance should, where applicable, include:

• (a) Developer name;
• (b) registered email;
• (c) account or workspace identifier;
• (d) project identifier;
• (e) transaction identifier;
• (f) relevant API endpoint;
• (g) date and time;
• (h) description of the issue;
• (i) previous support reference;
• (j) relevant evidence; and
• (k) requested resolution.

23.1 Developers may provide documents or evidence reasonably necessary to support a grievance.

23.2 Developers should not submit unnecessary personal or sensitive information.

24.1 Developers should redact unnecessary:

• (a) passwords;
• (b) API keys;
• (c) authentication codes;
• (d) identity documents;
• (e) payment credentials;
• (f) personal information; and
• (g) confidential information.

25.1 Developers must never provide API secrets, passwords, OTPs, private keys, webhook secrets, or similar credentials merely to substantiate a grievance.

25.2 StampMitra support personnel should not require disclosure of such secrets.

26.1 Legal and policy grievances may be submitted to:

[email protected]

26.2 Technical and operational matters may be submitted through the applicable StampMitra support portal.

26.3 StampMitra may redirect a grievance to the appropriate specialised team.

27.1 StampMitra may acknowledge receipt of a grievance through the contact information provided.

27.2 An acknowledgement does not constitute acceptance of the allegations or requested remedy.

28.1 StampMitra may assign a reference number to a grievance.

28.2 Developers should use the reference number in subsequent correspondence.

29.1 The grievance may undergo an initial review to determine:

• (a) scope;
• (b) urgency;
• (c) responsible team;
• (d) applicable policy;
• (e) required evidence;
• (f) security implications; and
• (g) appropriate next steps.

30.1 Grievances may be classified according to their nature and materiality.

30.2 Possible classifications include:

• (a) routine;
• (b) service;
• (c) billing;
• (d) contractual;
• (e) privacy;
• (f) security;
• (g) legal;
• (h) urgent; or
• (i) critical.

31.1 A matter may be treated as urgent where delay could reasonably cause significant:

• (a) security harm;
• (b) data exposure;
• (c) financial harm;
• (d) legal harm;
• (e) service disruption; or
• (f) other material harm.

32.1 Critical security matters may be transferred immediately to the security function.

32.2 Security controls may be applied before the grievance investigation is completed.

33.1 StampMitra may review relevant:

• (a) account records;
• (b) API logs;
• (c) transaction records;
• (d) billing records;
• (e) support correspondence;
• (f) configuration information;
• (g) security records; and
• (h) other relevant information.

34.1 Investigation may be limited by:

• (a) unavailable external systems;
• (b) incomplete information;
• (c) legal restrictions;
• (d) privacy obligations;
• (e) third-party confidentiality;
• (f) security considerations; or
• (g) absence of sufficient evidence.

35.1 Certain grievances may involve an Underlying Service Provider, government system, payment system, verification source, telecommunications provider, or other external system.

35.2 StampMitra may investigate the external dependency to the extent reasonably possible.

36.1 StampMitra may withhold confidential information concerning Underlying Service Providers, commercial arrangements, technical architecture, security controls, or contractual relationships.

36.2 Such withholding does not prevent StampMitra from investigating the grievance.

37.1 Where the grievance concerns a decision made by a governmental, statutory, regulatory, judicial, or other competent authority, StampMitra may facilitate technical clarification but does not control the authority's decision.

38.1 Submission of a grievance does not guarantee:

• (a) reversal of a decision;
• (b) refund;
• (c) restoration of access;
• (d) transaction completion;
• (e) approval;
• (f) legal acceptance; or
• (g) any particular outcome.

39.1 StampMitra may take interim measures while investigating a grievance.

39.2 Interim measures may include:

• (a) credential rotation;
• (b) temporary restriction;
• (c) transaction hold;
• (d) additional verification;
• (e) account review; or
• (f) other reasonable protective action.

40.1 StampMitra will seek to ensure that good-faith grievance reporting is not treated as a policy violation solely because a Developer raised a legitimate concern.

40.2 This does not protect fraudulent, abusive, or unlawful conduct.

41.1 StampMitra may communicate with the complainant through registered email, support portal, or another appropriate channel.

41.2 Developers are responsible for maintaining accurate contact information.

42.1 StampMitra may request additional information reasonably required to investigate a grievance.

42.2 Failure to provide requested information may limit the ability to investigate or resolve the matter.

43.1 StampMitra may provide a written response after review.

43.2 The response may include:

• (a) findings;
• (b) action taken;
• (c) explanation;
• (d) applicable policy;
• (e) limitations;
• (f) remediation requirements; or
• (g) available escalation options.

44.1 A response may contain confidential, security-sensitive, personal, commercially sensitive, or legally protected information.

44.2 The complainant must handle such information appropriately.

45.1 StampMitra may provide only the portion of an investigation result that can lawfully and safely be disclosed.

45.2 Security or privacy considerations may limit the detail provided.

46.1 Where a grievance is substantiated, StampMitra may take reasonable remedial action.

46.2 Remedial action may include:

• (a) correcting an account configuration;
• (b) correcting a billing record;
• (c) restoring an eligible service;
• (d) issuing an applicable credit;
• (e) improving documentation;
• (f) correcting a technical issue; or
• (g) implementing other appropriate measures.

47.1 A substantiated grievance does not automatically create an entitlement to monetary compensation.

47.2 Any refund, credit, service credit, or other financial remedy is governed by the applicable commercial and billing terms.

48.1 Where an investigation establishes a billing error attributable to StampMitra, an appropriate correction may be made subject to applicable policy and law.

49.1 Refund requests will be evaluated under the Billing, API Credits & Refund Policy and applicable Service terms.

50.1 Service credits, where available, are governed by applicable commercial terms or Enterprise agreements.

50.2 This Policy does not create an independent service-credit entitlement.

51.1 Privacy-related remedies will be handled according to applicable privacy law, the Developer Privacy Policy, and the Data Processing Addendum where applicable.

52.1 A grievance is not automatically a data-subject rights request.

52.2 Developers should clearly identify a request relating to access, correction, deletion, withdrawal, restriction, or another statutory data right.

53.1 Security-related matters may result in immediate protective measures.

53.2 Remediation may include credential revocation, key rotation, access restriction, additional authentication, or other security controls.

54.1 Where an account was restricted incorrectly and restoration is appropriate, StampMitra may restore access subject to security and compliance checks.

55.1 Developers may request review of a Production approval decision.

55.2 StampMitra may require additional information regarding:

• (a) identity;
• (b) business or project;
• (c) use case;
• (d) security;
• (e) expected API traffic;
• (f) data processing; or
• (g) regulatory considerations.

56.1 Verification outcomes may depend on external information sources.

56.2 StampMitra may explain the technical result where possible but may not be able to alter the underlying source decision.

57.1 e-Stamp grievances may involve:

• (a) Transaction status;
• (b) payment status;
• (c) issuance;
• (d) incorrect information;
• (e) cancellation;
• (f) refund;
• (g) authority requirements; or
• (h) external processing.

58.1 e-Sign grievances may involve:

• (a) signer authentication;
• (b) OTP;
• (c) document presentation;
• (d) signature status;
• (e) audit trail;
• (f) failed signing;
• (g) duplicate signing; or
• (h) external signature systems.

59.1 StampMitra may review technical or service issues concerning documents.

59.2 StampMitra does not provide legal opinions merely through grievance handling.

60.1 Where a grievance arises from an external service, StampMitra may coordinate internally or with the relevant external system as appropriate.

60.2 StampMitra may not be able to disclose confidential third-party information.

61.1 Where the appropriate remedy lies directly with an external authority, StampMitra may inform the Developer that the Developer must use the applicable authority's process.

62.1 Formal legal notices should be sent in accordance with the notice provisions of the Developer Terms of Service.

62.2 A routine support ticket does not automatically constitute a formal legal notice.

63.1 Requests from law enforcement or competent authorities will be handled according to applicable law.

64.1 Nothing in this Policy prevents a Developer from contacting a competent regulatory or statutory authority where legally entitled to do so.

65.1 Where a Developer is dissatisfied with an initial response, the Developer may request escalation through the applicable support or legal channel.

65.2 The escalation request should explain the unresolved issue and provide the relevant reference number.

66.1 An escalated grievance may be reviewed by a person or team with appropriate authority or subject-matter responsibility.

67.1 Where appropriate, a second-level review may consider:

• (a) the original grievance;
• (b) evidence;
• (c) previous findings;
• (d) applicable policies;
• (e) new information; and
• (f) requested remedy.

68.1 StampMitra may issue a final internal response after completion of the applicable review.

68.2 A final internal response does not waive statutory or contractual rights available to either party.

69.1 A closed grievance may be reopened where:

• (a) material new evidence becomes available;
• (b) a material error is identified;
• (c) circumstances materially change; or
• (d) applicable law requires reconsideration.

70.1 StampMitra may consolidate materially identical grievances to avoid duplicate investigations.

71.1 Where the same matter is submitted through multiple channels, StampMitra may consolidate the communications under one reference.

72.1 A Developer may appoint a representative to communicate regarding a grievance.

72.2 StampMitra may verify the representative's authority.

73.1 Where a grievance is submitted through legal counsel, StampMitra may communicate through the authorised legal representative.

74.1 Grievance information will be handled subject to applicable confidentiality, privacy, security, legal, and operational requirements.

75.1 StampMitra will seek to limit grievance processing to information reasonably necessary to investigate and resolve the matter.

76.1 StampMitra may retain grievance records for reasonable periods necessary for:

• (a) investigation;
• (b) compliance;
• (c) dispute resolution;
• (d) legal defence;
• (e) audit;
• (f) security; and
• (g) service improvement.

77.1 Grievance records may contain confidential or personal information and will be subject to appropriate security controls.

78.1 StampMitra may analyse aggregated or appropriately protected grievance information to identify recurring problems and improve Services.

79.1 Grievances may be used to improve:

• (a) documentation;
• (b) API design;
• (c) support procedures;
• (d) billing processes;
• (e) security controls;
• (f) user experience; and
• (g) operational processes.

80.1 StampMitra personnel should not retaliate against a Developer for submitting a genuine grievance.

81.1 StampMitra may restrict communications involving threats, harassment, discriminatory abuse, intimidation, or other unlawful conduct while preserving legitimate access to complaint mechanisms.

82.1 This Policy is not an emergency response service.

82.2 Security emergencies should be reported through the applicable security reporting channel.

83.1 During a widespread outage, StampMitra may provide information through its status or service communication channels rather than responding individually to every duplicate complaint.

84.1 Where a grievance concerns a security or data incident, the Incident & Breach Notification Procedure may apply.

85.1 StampMitra may be contractually restricted from disclosing the identity, pricing, technical arrangements, or communications of an Underlying Service Provider.

86.1 A Developer's grievance with StampMitra does not create a direct contractual relationship between the Developer and any Underlying Service Provider.

87.1 Commercial arrangements, pricing, routing, provider agreements, and internal operational information may be withheld where confidential.

88.1 StampMitra may withhold security-sensitive information where disclosure could facilitate exploitation, circumvention, fraud, or unauthorised access.

89.1 StampMitra may consider technical records, system logs, timestamps, transaction identifiers, communications, configuration records, and other relevant evidence.

90.1 Developers should preserve relevant evidence before changing configurations or deleting records where a material dispute exists.

91.1 StampMitra may rely on system records maintained through its ordinary technical and security processes, subject to applicable law.

92.1 StampMitra will seek to investigate genuine grievances reasonably and proportionately based on available information.

93.1 StampMitra may determine the appropriate investigation method based on the nature and sensitivity of the grievance.

94.1 Evidence originating from external systems may be considered subject to authenticity, availability, confidentiality, and legal limitations.

95.1 Fraud-related grievances may require enhanced verification.

95.2 StampMitra may temporarily restrict affected transactions or accounts while investigating suspected fraud.

96.1 Where identity fraud is suspected, StampMitra may require additional identity or account verification.

97.1 Payment-related fraud may be investigated under applicable billing and security procedures.

98.1 Account takeover concerns should be reported immediately.

98.2 StampMitra may revoke credentials and apply protective restrictions.

99.1 Suspected personal-data exposure should be reported promptly.

99.2 Such reports may be handled under the applicable security and privacy procedures.

100.1 Reports of API abuse may be investigated under the API Acceptable Use Policy and API Security Policy.

101.1 Reports concerning forged, altered, or fraudulent Documents may be escalated for investigation and may be reported to competent authorities where legally required or appropriate.

102.1 Reports concerning unauthorised signatures may be investigated using available transaction and authentication records.

103.1 Reports concerning fraudulent or altered e-Stamp Transactions may be subject to enhanced review.

104.1 Production access decisions may consider security, use case, verification, traffic, compliance, and operational factors.

105.1 Sandbox functionality may differ from Production.

105.2 Sandbox limitations do not necessarily constitute a service defect.

106.1 Documentation concerns should identify the specific page, endpoint, version, or instruction involved.

107.1 API lifecycle grievances are governed additionally by the API Versioning, Suspension & Deprecation Policy.

108.1 Where a grievance concerns interpretation of a Developer Policy, StampMitra may review the relevant policy language and applicable circumstances.

109.1 Where policies conflict, the order of precedence specified in the Developer Terms of Service shall apply.

110.1 A grievance process does not replace the formal dispute-resolution procedure contained in the Developer Terms of Service.

111.1 Developers may use the grievance process to seek clarification or resolution before initiating formal proceedings where appropriate.

111.2 Nothing prevents either party from seeking urgent legal relief where legally available.

112.1 Where a dispute is subject to arbitration under the Developer Terms of Service, the arbitration provisions of that agreement shall govern.

113.1 Nothing in this Policy limits a party's right to seek remedies available under applicable law.

114.1 This Policy does not contractually exclude rights that cannot lawfully be excluded.

115.1 Where a Developer or End User has mandatory statutory rights under applicable consumer law, those rights remain unaffected.

116.1 StampMitra will handle grievances in accordance with applicable legal and regulatory requirements.

117.1 Where a competent authority requires information concerning a grievance, StampMitra may provide information as legally required.

118.1 Where a Developer or End User is located outside India, applicable cross-border legal requirements may affect grievance handling.

119.1 Grievances may be submitted in English or another language supported by the applicable support channel.

119.2 StampMitra may provide the formal response in English unless otherwise required by law.

120.1 StampMitra will seek to provide reasonable accessibility in grievance communications consistent with available systems and applicable law.

121.1 During major operational disruptions, grievance handling may be prioritised according to severity and available resources.

122.1 During widespread incidents, StampMitra may use central incident communications to address common issues.

123.1 Developers should consult applicable service-status communications during known incidents before submitting duplicate complaints.

124.1 Support interactions may be recorded or retained for service, security, quality, training, compliance, and dispute-resolution purposes subject to applicable law.

125.1 Where applicable and lawfully implemented, communications through support systems may be logged or retained.

126.1 StampMitra will not disclose another Developer's confidential information merely because it is requested as part of a grievance.

127.1 Personal information concerning other persons will not be disclosed except where lawfully permitted or required.

128.1 StampMitra may assign a grievance to personnel reasonably appropriate to the subject matter.

128.2 Where a material conflict is identified, StampMitra may reassign the review.

129.1 Where appropriate, StampMitra may conduct an additional internal review by personnel not involved in the original decision.

130.1 After the applicable internal review is completed, StampMitra may treat the grievance as internally resolved, subject to any contractual or statutory rights.

131.1 Repeated requests based on the same facts without material new information may be closed or consolidated.

132.1 StampMitra may record the outcome as:

• (a) substantiated;
• (b) partially substantiated;
• (c) unsubstantiated;
• (d) unable to determine;
• (e) resolved;
• (f) withdrawn;
• (g) redirected; or
• (h) closed for another valid reason.

133.1 A Developer may withdraw a grievance where appropriate.

133.2 Withdrawal does not prevent StampMitra from continuing an investigation where required for security, legal, compliance, or other legitimate reasons.

134.1 Participation in the grievance process does not by itself constitute an admission, waiver, or concession by either party.

135.1 Where appropriate, parties may resolve a grievance through a confidential written arrangement.

136.1 Any settlement or commercial concession must be approved through the appropriate authority within BANI GLOBAL INDUSTRIES LLP.

137.1 Support personnel are not authorised to amend contractual terms or create financial obligations on behalf of StampMitra unless expressly authorised.

138.1 This Policy is administered by BANI GLOBAL INDUSTRIES LLP.

139.1 StampMitra may periodically review this Policy for legal, operational, security, and regulatory adequacy.

140.1 StampMitra may update this Policy to reflect changes in law, technology, organisational structure, Services, or grievance procedures.

141.1 Updated versions become effective on the stated effective date.

141.2 Continued use of the Developer Services after the effective date may constitute acceptance to the extent permitted by applicable law.

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

143.1 Failure to enforce any provision does not constitute a waiver of future enforcement.

144.1 Unless expressly stated otherwise, this Policy does not create third-party beneficiary rights.

145.1 This Policy should be read together with:

• (a) Developer Terms of Service;
• (b) Developer Privacy Policy;
• (c) Data Processing Addendum;
• (d) API Acceptable Use Policy;
• (e) Third-Party & Underlying Services Policy;
• (f) API Security Policy;
• (g) API SLA & Service Availability Policy;
• (h) Billing, API Credits & Refund Policy;
• (i) Verification, e-Stamp & e-Sign Service Terms; and
• (j) API Versioning, Suspension & Deprecation Policy.

146.1 In the event of inconsistency, the order of precedence in the Developer Terms of Service shall apply.

147.1 This Policy is governed by the governing law provisions of the StampMitra Developer Terms of Service, subject to applicable Indian law.

148.1 Formal disputes shall be handled in accordance with the dispute-resolution provisions of the StampMitra Developer Terms of Service.

149.1 Legal and grievance correspondence:

[email protected]

149.2 Developer Platform:

https://developer.stampmitra.in/

150.1 By using StampMitra Developer Services, the Developer acknowledges that:

• (a) legitimate grievances may be submitted through applicable channels;
• (b) sufficient information should be provided for investigation;
• (c) security matters may be handled through specialised procedures;
• (d) privacy matters may be subject to separate legal procedures;
• (e) billing matters are governed by applicable billing terms;
• (f) confidentiality may limit information disclosed during an investigation;
• (g) a grievance does not automatically create a right to compensation or restoration;
• (h) statutory and contractual rights remain unaffected; and
• (i) this Policy forms part of the StampMitra Developer Policy Framework.

• Policy Name: Developer Grievance Redressal Policy
• Policy Number: 11 of 19
• Version: 1.0
• Status: FINAL — PUBLISHED POLICY
• Effective Date: 05 October 2026
• Last Updated: 05 October 2026
• Legal Entity: BANI GLOBAL INDUSTRIES LLP
• Prepared By: Legal Team
• Legal Contact: [email protected]