Developer Data Retention & Deletion Schedule

This Developer Data Retention & Deletion Schedule (“Schedule”) establishes the principles and operational framework used by BANI GLOBAL INDUSTRIES LLP (“BANI GLOBAL INDUSTRIES LLP”, “StampMitra”, “we”, “us”, or “our”) for retaining, deleting, anonymising, restricting, or otherwise disposing of information processed through the StampMitra Developer Platform.

This Schedule is intended to be read together with:

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

This Schedule does not create a promise that every category of information will be retained for a fixed number of days.

Retention depends on the nature of the information, the purpose for which it was collected, legal and regulatory requirements, contractual obligations, security requirements, transaction status, dispute status, accounting requirements, operational requirements, and whether deletion is technically or legally appropriate.

Where a specific retention period is not expressly stated, StampMitra may retain information for a reasonable period necessary to fulfil the relevant purpose, protect legitimate interests, comply with applicable law, resolve disputes, maintain security, or satisfy contractual and regulatory obligations.

1.1 The purpose of this Schedule is to establish a consistent framework for retention and deletion of information processed through StampMitra.

1.2 The Schedule is designed to support:

• (a) data minimisation;
• (b) purpose limitation;
• (c) privacy compliance;
• (d) security;
• (e) operational continuity;
• (f) financial and accounting requirements;
• (g) transaction reconciliation;
• (h) fraud prevention;
• (i) legal compliance;
• (j) dispute management;
• (k) auditability; and
• (l) controlled deletion.

2.1 This Schedule applies to information processed in connection with the StampMitra Developer Platform, including information relating to:

• (a) Developer accounts;
• (b) Individual Developers;
• (c) Organization Developers;
• (d) workspaces;
• (e) projects;
• (f) Sandbox environments;
• (g) Production environments;
• (h) API credentials;
• (i) API requests and responses;
• (j) API logs;
• (k) webhooks;
• (l) security events;
• (m) billing;
• (n) invoices;
• (o) API credits;
• (p) verification services;
• (q) e-Stamp services;
• (r) e-Sign services;
• (s) legal-document services;
• (t) support interactions;
• (u) grievances;
• (v) incidents;
• (w) audit records;
• (x) consent and preference information; and
• (y) other information processed in connection with StampMitra services.

2.2 This Schedule applies to personal data and non-personal operational information where retention or deletion controls are appropriate.

3.1 StampMitra's role may differ depending on the nature and purpose of the processing.

3.2 StampMitra may act as a Data Fiduciary, Data Processor, independent controller-equivalent party, service provider, or in another legally applicable capacity depending on the relevant processing activity.

3.3 Retention obligations may therefore differ between:

• (a) Developer Account Data;
• (b) Developer Data submitted through an API;
• (c) End User Data;
• (d) operational and security information;
• (e) billing information; and
• (f) information processed independently for legal, security, or compliance purposes.

3.4 Where a DPA applies, its deletion and return provisions shall govern Developer Data processed by StampMitra as a processor to the extent of any express conflict.

4.1 “Retention” means continued storage or preservation of information.

4.2 “Deletion” means removal or destruction of information from an active system where technically and legally appropriate.

4.3 “Erasure” means deletion or irreversible removal of information from a relevant processing system.

4.4 “Anonymisation” means processing information so that an individual is no longer reasonably identifiable from the resulting information, taking into account reasonably available means.

4.5 “Restriction” means limiting the processing or accessibility of information without necessarily deleting it.

4.6 “Developer Account Data” means information associated with a Developer account, including registration, identity, contact, authentication, workspace, and account administration information.

4.7 “Developer Data” means information submitted to or processed through the StampMitra API on behalf of a Developer where StampMitra acts in a processor or equivalent capacity.

4.8 “API Operational Data” means technical information generated through API usage, including request metadata, response metadata, timestamps, system events, performance information, and related operational records.

4.9 “Security Data” means information used to detect, prevent, investigate, or respond to security incidents, fraud, abuse, unauthorized access, or other security threats.

4.10 “Billing Data” means information necessary to calculate, invoice, reconcile, collect, dispute, refund, or account for charges.

4.11 “Legal Hold” means a requirement to preserve information because of actual or reasonably anticipated litigation, investigation, dispute, regulatory action, government request, audit, or other legal requirement.

4.12 “Backup” means a secondary copy of data maintained for recovery, continuity, resilience, or disaster-recovery purposes.

5.1 StampMitra shall seek to retain information only for as long as reasonably necessary for the relevant purpose or legal obligation.

5.2 StampMitra shall avoid indefinite retention merely for convenience where there is no legitimate requirement for continued retention.

5.3 Different categories of information may have different retention periods.

5.4 Deletion may be delayed where necessary to satisfy:

• (a) legal obligations;
• (b) regulatory obligations;
• (c) accounting obligations;
• (d) tax requirements;
• (e) contractual obligations;
• (f) security requirements;
• (g) fraud investigations;
• (h) dispute resolution;
• (i) chargeback management;
• (j) audit requirements;
• (k) legal holds; or
• (l) business continuity requirements.

6.1 The following schedule provides the governing retention framework.

6.2 Where a specific period is stated below, it is subject to applicable law, legal hold, contractual obligations, security requirements, and technical limitations.

6.3 Where no fixed period is stated, StampMitra may determine a reasonable retention period based on the applicable purpose and risk.

6.4 The table is a framework and not an exhaustive list of every data category processed by StampMitra.

7.1 Developer registration information may include:

• (a) name;
• (b) email address;
• (c) mobile number;
• (d) account type;
• (e) organization information;
• (f) country or jurisdiction;
• (g) verification information;
• (h) account identifiers;
• (i) onboarding information; and
• (j) other information reasonably necessary to establish an account.

7.2 Such information may generally be retained for the active life of the account.

7.3 Following account closure, information may continue to be retained where necessary for legal, accounting, security, fraud-prevention, dispute, or regulatory purposes.

8.1 Verification information may include information required to verify Developer identity, organization details, authority, eligibility, or Production access.

8.2 Verification information may be retained for as long as reasonably necessary to:

• (a) establish account eligibility;
• (b) maintain Production authorization;
• (c) prevent fraud;
• (d) satisfy legal obligations;
• (e) investigate disputes; or
• (f) maintain an appropriate audit trail.

8.3 StampMitra may delete or restrict access to verification documents when they are no longer required, subject to applicable legal and operational requirements.

9.1 API credentials are security-sensitive information.

9.2 Active credentials may be retained only for as long as required for authentication and authorized service operation.

9.3 Revoked, rotated, expired, or compromised credentials may be retained in limited form for security, audit, fraud-prevention, or forensic purposes.

9.4 StampMitra may retain credential metadata without retaining the full secret value.

9.5 Full secret values may not be recoverable after creation or rotation where the relevant system is designed for one-time secret display.

10.1 Session information may be retained only for the relevant session, security lifecycle, or associated operational requirement.

10.2 Expired session identifiers may be invalidated.

10.3 Security records relating to suspicious or compromised sessions may be retained for a longer period where reasonably necessary for investigation.

11.1 API request and response information may contain Developer Data, technical metadata, transaction information, or other information depending on the API.

11.2 StampMitra shall seek to retain such information only for purposes reasonably connected with:

• (a) service delivery;
• (b) transaction processing;
• (c) reconciliation;
• (d) troubleshooting;
• (e) security;
• (f) support;
• (g) audit;
• (h) legal compliance; or
• (i) contractual requirements.

11.3 Developers should not submit information that is unnecessary for the requested API operation.

12.1 API logs may include:

• (a) timestamps;
• (b) endpoint information;
• (c) request identifiers;
• (d) status codes;
• (e) latency;
• (f) IP information;
• (g) authentication events;
• (h) error information;
• (i) rate-limit events;
• (j) security signals; and
• (k) other technical metadata.

12.2 Logs may be retained for operational, security, troubleshooting, capacity-management, compliance, and audit purposes.

12.3 Sensitive payload content should not be unnecessarily replicated in general-purpose logs.

13.1 Request identifiers may be retained to support transaction tracing, debugging, incident investigation, reconciliation, and support.

13.2 Such identifiers may remain in operational records after the associated transaction data is deleted where necessary for security or audit purposes.

14.1 Webhook delivery information may be retained to determine whether an event was successfully delivered.

14.2 Records may include:

• (a) event identifiers;
• (b) delivery timestamps;
• (c) response status;
• (d) retry information;
• (e) endpoint information;
• (f) signature verification status; and
• (g) related operational information.

14.3 Webhook payloads may be subject to separate retention controls based on their content and purpose.

15.1 Idempotency keys, transaction identifiers, reconciliation information, and duplicate-prevention records may be retained for as long as reasonably necessary to prevent duplicate processing and reconcile transactions.

15.2 Such information may remain after a transaction is completed where necessary to prevent replay or duplication.

16.1 Billing information may include:

• (a) billing identity;
• (b) invoices;
• (c) transaction references;
• (d) payment status;
• (e) tax information;
• (f) credit information;
• (g) refund records;
• (h) payment disputes;
• (i) chargeback information; and
• (j) accounting records.

16.2 Billing information may be retained for the period required by applicable accounting, tax, legal, contractual, or dispute-resolution requirements.

16.3 Account closure does not automatically result in immediate deletion of billing records.

17.1 Information required for taxation, invoicing, accounting, statutory reporting, financial reconciliation, or audit may be retained for the period required under applicable law.

17.2 Where legal requirements prescribe a specific retention period, the applicable statutory period shall prevail.

18.1 Records concerning purchased, granted, consumed, expired, adjusted, or refunded API credits may be retained for commercial and accounting purposes.

18.2 Credit balances may be deleted or archived following account closure, subject to contractual and financial requirements.

18.3 Historical credit transactions may remain available in accounting or audit records even after the active balance becomes zero.

19.1 Transaction records may include information necessary to establish whether a transaction was:

• (a) initiated;
• (b) pending;
• (c) successful;
• (d) failed;
• (e) rejected;
• (f) cancelled;
• (g) refunded; or
• (h) otherwise concluded.

19.2 Transaction records may be retained for legal, financial, operational, support, security, and reconciliation purposes.

20.1 Verification requests and results may be retained where reasonably necessary for:

• (a) service delivery;
• (b) transaction records;
• (c) fraud prevention;
• (d) dispute resolution;
• (e) audit;
• (f) regulatory compliance; or
• (g) legal obligations.

20.2 Verification data shall not be retained indefinitely merely because it was once processed.

21.1 e-Stamp-related information may require retention beyond ordinary API logs because it may relate to a legally significant transaction or instrument.

21.2 Relevant records may include:

• (a) request information;
• (b) transaction identifiers;
• (c) instrument information;
• (d) payment status;
• (e) issuance status;
• (f) cancellation or correction information;
• (g) relevant documents;
• (h) audit information; and
• (i) other information required to establish the transaction history.

21.3 Retention shall be determined by applicable law, service requirements, transaction status, contractual requirements, and legitimate operational needs.

22.1 e-Sign information may include identity, authentication, document, consent, timestamp, transaction, and audit-trail information.

22.2 Such information may be retained where necessary to establish the history, integrity, or status of an electronic signing transaction.

22.3 Retention may continue after document completion where legally or contractually necessary.

23.1 Documents submitted through StampMitra may be retained according to the purpose of processing and applicable contractual or legal requirements.

23.2 StampMitra may delete temporary or unnecessary document copies where they are no longer required.

23.3 Documents subject to legal, transaction, audit, or dispute requirements may be retained for longer periods.

23.4 Developers should not upload unnecessary personal or confidential documents.

24.1 Identity documents may require enhanced protection and controlled retention.

24.2 Where an identity document is no longer required, StampMitra may delete or restrict access to it subject to applicable law and audit requirements.

24.3 Metadata or evidence that verification occurred may be retained after the underlying identity document is deleted where reasonably necessary.

25.1 Support tickets, correspondence, technical information, and resolution records may be retained for:

• (a) customer support;
• (b) quality assurance;
• (c) dispute resolution;
• (d) security;
• (e) training and service improvement where lawful;
• (f) audit; and
• (g) legal requirements.

25.2 Support records may contain personal information and shall be subject to appropriate access controls.

26.1 Grievance records may be retained to establish:

• (a) receipt of the grievance;
• (b) investigation;
• (c) communications;
• (d) findings;
• (e) resolution;
• (f) escalation; and
• (g) compliance with applicable grievance obligations.

26.2 Grievance information may be retained for a period reasonably necessary to protect the rights of the parties and demonstrate compliance.

27.1 Security incident records may require extended retention.

27.2 Such records may include:

• (a) incident reports;
• (b) security alerts;
• (c) forensic information;
• (d) access records;
• (e) affected systems;
• (f) remediation actions;
• (g) communications;
• (h) evidence;
• (i) root-cause information; and
• (j) post-incident actions.

27.3 Security records may be retained longer than ordinary operational logs where reasonably necessary to identify recurring threats or satisfy legal requirements.

28.1 Information relating to suspected fraud, abuse, credential compromise, document fraud, unauthorized access, or API misuse may be retained for the duration reasonably necessary to investigate and resolve the matter.

28.2 Such information may be retained beyond ordinary account deletion where necessary to prevent repeated abuse or satisfy legal obligations.

29.1 Audit records may include administrative actions, security actions, account changes, credential events, Production approvals, billing adjustments, policy actions, and other controlled events.

29.2 Audit records may be retained for security, compliance, legal, commercial, or operational purposes.

29.3 Audit records may be retained after associated account information has otherwise been deleted where necessary to preserve evidence of the action.

30.1 Where consent is collected, StampMitra may retain evidence of:

• (a) consent status;
• (b) date or time;
• (c) relevant version;
• (d) consent category;
• (e) withdrawal; and
• (f) related technical information.

30.2 Such records may be retained to demonstrate compliance with applicable privacy requirements.

31.1 Cookie-related data is generally retained according to the relevant purpose and the StampMitra Cookie & Tracking Policy.

31.2 Security-related identifiers may be retained longer where necessary for security or fraud prevention.

31.3 Deleting a browser Cookie does not necessarily delete server-side records associated with the relevant session or activity.

32.1 Transactional, security, account, billing, and support communications may be retained where reasonably necessary to establish delivery, support account administration, resolve disputes, or satisfy legal requirements.

32.2 Marketing communication records may be subject to separate preference and compliance controls.

33.1 Opt-in, opt-out, subscription, and communication preference records may be retained to honour the relevant preference.

33.2 Evidence of a previous preference may be retained to prevent unintended re-subscription or repeated unwanted communication.

34.1 A Developer may request account closure subject to applicable procedures.

34.2 Account closure does not necessarily cause immediate deletion of all information.

34.3 StampMitra may first:

• (a) complete pending transactions;
• (b) reconcile billing;
• (c) resolve disputes;
• (d) preserve security records;
• (e) satisfy legal obligations;
• (f) complete required exports; and
• (g) apply applicable deletion controls.

35.1 Where applicable law provides a right to deletion or erasure, StampMitra will process a valid request in accordance with the applicable legal framework.

35.2 StampMitra may require reasonable verification before executing a deletion request concerning an account.

35.3 Verification is intended to prevent unauthorized deletion of another person's account or information.

36.1 Information may remain where deletion would conflict with:

• (a) applicable law;
• (b) tax obligations;
• (c) accounting obligations;
• (d) legal proceedings;
• (e) regulatory investigations;
• (f) fraud prevention;
• (g) security investigations;
• (h) contractual rights;
• (i) payment disputes;
• (j) chargebacks;
• (k) audit requirements; or
• (l) legitimate legal preservation obligations.

36.2 Where deletion is legally restricted, StampMitra may restrict processing instead of deleting the information.

37.1 A Legal Hold may suspend ordinary deletion schedules.

37.2 A Legal Hold may apply where information is relevant to:

• (a) litigation;
• (b) threatened litigation;
• (c) government investigation;
• (d) regulatory action;
• (e) dispute;
• (f) fraud investigation;
• (g) security incident;
• (h) audit; or
• (i) another legally recognized preservation requirement.

37.3 Information subject to a Legal Hold shall not be intentionally destroyed until the relevant preservation requirement is released.

38.1 Information associated with disputed, reversed, refunded, or charged back transactions may be retained until the matter is reasonably resolved.

38.2 Historical records may remain after resolution where required for financial or legal purposes.

39.1 Suspension does not automatically trigger deletion.

39.2 Termination may initiate the applicable deletion lifecycle.

39.3 Information associated with abuse, security incidents, fraud, disputes, or legal obligations may remain subject to appropriate restrictions.

40.1 Removal of Production access does not necessarily require deletion of historical account, billing, security, or transaction records.

40.2 Production credentials may be revoked or invalidated immediately where appropriate.

41.1 Retirement of an API version does not necessarily result in immediate deletion of historical records.

41.2 Historical information may be retained for operational, security, billing, legal, audit, and transaction purposes.

41.3 The API Versioning, Suspension & Deprecation Policy governs lifecycle management of API versions.

42.1 Sandbox information may be retained for testing, debugging, security, service improvement, or operational purposes.

42.2 Developers should use synthetic, fictional, anonymised, or otherwise non-production data in Sandbox.

42.3 StampMitra may delete Sandbox data more aggressively where appropriate.

42.4 Production personal data must not be intentionally copied into Sandbox unless expressly authorized and legally appropriate.

43.1 Test data should be designed to minimise privacy risk.

43.2 Developers should avoid using real identity documents, financial information, sensitive personal information, or unnecessary personal data in testing.

43.3 StampMitra may remove test data that presents unnecessary security or privacy risk.

44.1 Deletion from active systems may not immediately result in deletion from backups.

44.2 Backups may be retained for disaster recovery, business continuity, security, and operational resilience.

44.3 Backup data shall be subject to access controls appropriate to its purpose.

44.4 Where technically practicable, deleted information shall not be restored to active systems except where necessary for legitimate recovery or legal purposes.

45.1 Backups may be overwritten, rotated, expired, or otherwise disposed of according to StampMitra's infrastructure and business-continuity configuration.

45.2 StampMitra does not promise a specific backup deletion interval unless expressly provided under an applicable commercial agreement.

46.1 During disaster recovery, information previously marked for deletion may temporarily appear in restored systems where technically unavoidable.

46.2 StampMitra will apply reasonable controls to reapply applicable deletion requirements after restoration.

47.1 Information may be archived where immediate deletion is not appropriate but active processing is no longer necessary.

47.2 Archived information may have restricted access.

47.3 Archived information shall not be treated as freely available operational data.

48.1 StampMitra may retain properly anonymised information for legitimate purposes where it is no longer reasonably identifiable as personal data.

48.2 Such purposes may include:

• (a) statistical analysis;
• (b) service improvement;
• (c) capacity planning;
• (d) security research;
• (e) product development; and
• (f) aggregate reporting.

48.3 Anonymisation shall not be claimed where reasonable means remain available to identify an individual.

49.1 Aggregated information may be retained where it no longer reasonably identifies an individual or confidential Developer information.

49.2 Aggregation does not authorize disclosure of confidential commercial information.

50.1 When information reaches the end of its applicable retention period, StampMitra may:

• (a) delete it;
• (b) anonymise it;
• (c) aggregate it;
• (d) restrict access;
• (e) archive it; or
• (f) otherwise dispose of it appropriately.

50.2 The selected method shall depend on the nature of the information and applicable legal and technical requirements.

51.1 StampMitra shall seek to use reasonable technical processes for secure deletion of information from systems under its control.

51.2 Secure deletion may involve deletion of records, destruction of storage objects, invalidation of identifiers, cryptographic or infrastructure controls, or other appropriate technical measures.

51.3 The exact deletion mechanism may vary by system architecture.

52.1 StampMitra may use external service providers for hosting, security, communications, payments, analytics, support, infrastructure, or other functions.

52.2 Where StampMitra controls the relevant processing relationship, reasonable contractual or operational measures may be used to address retention and deletion.

52.3 Some third-party systems may have independent retention obligations.

52.4 StampMitra does not guarantee immediate deletion from every external system following deletion from StampMitra's active systems where the external system has a separate lawful retention requirement.

53.1 Certain StampMitra services depend on Authorized Underlying Service Providers, external systems, government-related systems, data sources, or other service dependencies.

53.2 Information transmitted to such systems may be subject to their own legal and operational retention requirements.

53.3 StampMitra shall not represent that every record transmitted to an external system can be immediately deleted solely because a Developer requests deletion from StampMitra.

53.4 The StampMitra Third-Party & Underlying Services Policy applies.

54.1 Certain records may be required to be retained because of governmental, regulatory, statutory, tax, stamping, electronic-signature, verification, or other legal requirements.

54.2 StampMitra may preserve such records for the legally required period.

55.1 Payment-related records may be retained to support:

• (a) payment reconciliation;
• (b) refunds;
• (c) chargebacks;
• (d) fraud prevention;
• (e) accounting;
• (f) tax compliance;
• (g) dispute resolution; and
• (h) legal requirements.

55.2 Payment credentials or sensitive authentication data shall not be retained unnecessarily.

56.1 Where a Developer submits End User information through StampMitra, retention shall depend on the processing role and purpose.

56.2 Developers are responsible for ensuring that information submitted to StampMitra is necessary and lawfully obtained.

56.3 Developers must not use StampMitra as an indefinite archival repository for unrelated End User data.

57.1 A Developer may request deletion of Developer Data where the applicable agreement or law provides such a right.

57.2 StampMitra may require sufficient information to identify the relevant data without requiring the Developer to disclose unnecessary additional personal information.

57.3 Where StampMitra acts as a processor, deletion requests shall be handled according to the applicable DPA and documented processing instructions.

58.1 Where contractually required, StampMitra may provide a reasonable mechanism for returning Developer Data before deletion.

58.2 Data return may be subject to:

• (a) account verification;
• (b) security controls;
• (c) technical limitations;
• (d) applicable format availability;
• (e) legal restrictions; and
• (f) applicable contractual terms.

58.3 StampMitra is not required to create a new export format solely for a particular deletion request unless expressly agreed.

59.1 Developers should export information required for their own records before account termination where appropriate.

59.2 Export functionality may vary by service.

59.3 Exporting data does not transfer StampMitra's legal obligations or authorize the Developer to retain data indefinitely contrary to applicable law.

60.1 Security information associated with account recovery may be retained for fraud prevention and security investigation.

60.2 Such records may include evidence of:

• (a) recovery requests;
• (b) OTP events;
• (c) authentication events;
• (d) credential changes;
• (e) device or session information; and
• (f) security decisions.

61.1 OTPs are security credentials and should not be retained in plaintext longer than technically necessary.

61.2 StampMitra may retain metadata regarding OTP generation, delivery, verification, failure, abuse detection, or security events.

61.3 Developers must not store OTPs unnecessarily in their own systems.

62.1 Passwords must not be retained in plaintext.

62.2 Authentication systems may retain appropriate cryptographic representations and security metadata necessary to authenticate users.

62.3 Password-related security events may be retained for security purposes.

63.1 Webhook secrets are security-sensitive credentials.

63.2 Active secrets may be retained only while required.

63.3 Revoked or rotated secrets may have limited metadata retained for security and audit purposes.

64.1 Access tokens, refresh tokens, session tokens, and similar credentials shall be handled as security-sensitive information.

64.2 Expired or revoked credentials may be retained in limited form for security, audit, or incident investigation.

65.1 StampMitra shall seek to avoid unnecessary personal information in general-purpose logs.

65.2 Developers must not intentionally submit passwords, API secrets, OTPs, private keys, or other unnecessary credentials in API parameters, logs, support tickets, or documents.

66.1 Temporary debugging information may be retained for troubleshooting.

66.2 Debugging information should be removed, restricted, or reduced when the troubleshooting purpose has been completed.

66.3 Production debugging shall be subject to appropriate security controls.

67.1 Performance data may include latency, throughput, error rates, capacity, availability, and other operational measurements.

67.2 Such information may be retained for capacity planning, troubleshooting, security, service improvement, and SLA analysis.

68.1 Analytics data may be retained according to its purpose and applicable privacy requirements.

68.2 StampMitra may aggregate or anonymise analytics information where appropriate.

68.3 Analytics information that is no longer necessary may be deleted or anonymised.

69.1 Attachments submitted through support channels may be retained as part of the relevant support or investigation record.

69.2 Users should not provide unnecessary sensitive documents through support channels.

69.3 StampMitra may delete unnecessary attachments after the relevant support purpose has concluded, subject to legal and security requirements.

70.1 Confidential commercial information may be retained as necessary to administer contractual relationships.

70.2 Confidentiality obligations may survive deletion of active system records where information remains known or preserved in lawful records.

71.1 Records necessary to establish ownership, licensing, authorization, commercial terms, or intellectual property rights may be retained as reasonably necessary.

72.1 Legal notices, formal complaints, contractual notices, regulatory communications, and related correspondence may be retained for the relevant legal or contractual period.

73.1 Information may be preserved or retained in response to lawful government or regulatory requests.

73.2 Where legally permitted, StampMitra may notify the affected party of such a request.

74.1 Preservation may temporarily override an ordinary deletion schedule.

74.2 Preservation shall be limited to the information reasonably relevant to the preservation requirement.

74.3 Once the preservation requirement ends, ordinary deletion procedures may resume.

75.1 StampMitra may maintain internal records showing that a deletion, restriction, anonymisation, or archival action occurred.

75.2 Such evidence may be retained without preserving the underlying deleted content.

76.1 Technical failure to delete information immediately does not automatically constitute intentional non-compliance.

76.2 StampMitra may identify, remediate, and retry deletion processes where technically necessary.

76.3 Information subject to an active deletion request may be restricted from ordinary processing while deletion is being completed where reasonably practicable.

77.1 Deletion shall not be performed in a manner that unnecessarily creates security vulnerabilities.

77.2 Certain security records may need to be retained to detect repeated attacks, investigate incidents, or prevent abuse.

78.1 StampMitra may delay deletion where immediate deletion would materially impair an active transaction, service recovery, security investigation, or legally required process.

78.2 Such delay shall not be interpreted as indefinite retention.

79.1 Deletion of account or API data does not automatically cancel outstanding financial obligations.

79.2 Billing records may be preserved independently of account data where required.

80.1 Information required to process a refund may be retained until the refund is completed and any related dispute period has reasonably concluded.

80.2 Historical refund records may remain in financial records.

81.1 Chargeback information may require retention beyond account closure.

81.2 Relevant records may be retained to respond to payment disputes, financial claims, or legal proceedings.

82.1 Fraud-prevention records may be retained where necessary to prevent repeated fraudulent activity.

82.2 Such retention shall be limited to legitimate security and fraud-prevention purposes.

83.1 Records relating to material API abuse may be retained to prevent circumvention through new accounts or credentials.

83.2 Retention shall not authorize unrelated use of such information.

84.1 Security research reports may be retained for vulnerability management, remediation, audit, and security improvement.

84.2 Personal information unrelated to the vulnerability shall not be retained unnecessarily.

85.1 Where applicable law provides rights relating to access, correction, erasure, restriction, portability, consent withdrawal, or other rights, StampMitra shall process valid requests according to the applicable legal framework.

85.2 StampMitra may take reasonable steps to verify the identity and authority of the requester.

86.1 Where information is inaccurate and a correction request is valid, StampMitra may update the information before determining whether deletion is appropriate.

86.2 Historical records may remain unchanged where they are required to accurately preserve transaction or audit history.

87.1 A Developer may request preservation of specific information where legally or contractually appropriate.

87.2 StampMitra may reject preservation requests that are overly broad, unlawful, technically unreasonable, or inconsistent with applicable requirements.

88.1 Exceptions to ordinary retention may be created for:

• (a) legal holds;
• (b) security investigations;
• (c) regulatory requirements;
• (d) tax requirements;
• (e) litigation;
• (f) fraud investigations;
• (g) contractual obligations;
• (h) disaster recovery;
• (i) transaction reconciliation; or
• (j) other legally legitimate purposes.

88.2 Exceptions shall be reviewed and removed when no longer required where reasonably practicable.

89.1 Retained information shall not automatically remain accessible to all employees, contractors, Developers, or users.

89.2 Access shall be subject to applicable authorization and security controls.

89.3 Archived or legally preserved information may have additional restrictions.

90.1 Internal personnel may access retained information only where reasonably necessary for their authorized role.

90.2 Privileged access may be logged or otherwise controlled.

91.1 Where StampMitra uses processors or subprocessors, relevant retention requirements may be addressed through applicable contractual arrangements.

91.2 The exact deletion timeline of a service provider may depend on its technical architecture and legally applicable obligations.

92.1 StampMitra may rely on reasonable contractual, operational, or technical assurances concerning deletion by service providers.

92.2 StampMitra is not required to obtain individualized deletion certificates for every record unless required by law or contract.

93.1 Where information is lawfully transmitted to an external system, its retention may be governed by that system's legal or operational requirements.

93.2 StampMitra shall not misrepresent its ability to delete records from systems outside its control.

94.1 StampMitra does not grant Developers an indefinite archival service through the API.

94.2 Developers are responsible for maintaining their own legally required records where appropriate.

95.1 Developers are responsible for managing retention and deletion of data stored in their own systems, backups, logs, analytics platforms, and applications.

95.2 A Developer's deletion of data from StampMitra does not automatically delete copies stored in the Developer's own environment.

96.1 Developers must ensure that their own application logs do not unnecessarily retain:

• (a) API secrets;
• (b) access tokens;
• (c) OTPs;
• (d) identity documents;
• (e) sensitive personal data; or
• (f) other unnecessary confidential information.

97.1 Developers are responsible for applying appropriate retention policies to Production data received through StampMitra.

97.2 StampMitra's deletion of data does not automatically remove copies maintained by the Developer.

98.1 Developers must not submit personal data merely because an API permits a field.

98.2 Developers should submit the minimum information reasonably necessary to perform the requested service.

99.1 Where a service involves sensitive or high-risk information, retention shall be limited to the relevant legitimate purpose and applicable requirements.

99.2 Developers must comply with any additional requirements applicable to such information.

100.1 Where children's data is processed, additional retention and deletion requirements may apply.

100.2 Developers must not use StampMitra services to retain children's data longer than legally or operationally necessary.

101.1 Retention does not imply that information is continuously verified for accuracy.

101.2 Developers are responsible for maintaining accurate information they submit where legally or operationally required.

102.1 Where portability or export rights apply, StampMitra may provide information in a reasonably available structured format.

102.2 Technical limitations may affect the exact format or completeness of certain historical records.

103.1 Derived information may include risk indicators, analytics, classification information, technical metadata, or aggregated information.

103.2 Where derived information remains personal data, applicable retention and deletion requirements may apply.

103.3 Properly anonymised derived information may be retained where lawful.

104.1 Where data is used for analytics, automated systems, or AI-related service improvement, StampMitra shall apply the applicable privacy and retention requirements.

104.2 Developers must not submit confidential or personal information for unrelated model training or experimentation unless expressly authorized.

105.1 Temporary cached information may exist in application or infrastructure layers.

105.2 Cache data may be automatically expired, invalidated, or overwritten.

105.3 Cache retention shall not be interpreted as a separate permanent storage service.

106.1 Data temporarily stored in processing queues may remain until processing is completed, failed, retried, expired, or otherwise concluded.

106.2 Failed or abandoned jobs may be subject to cleanup procedures.

107.1 Failed transactions may still require retention for troubleshooting, reconciliation, fraud prevention, audit, or dispute resolution.

107.2 Failure does not automatically mean that all associated data can be immediately deleted.

108.1 Pending transactions may be retained until they are resolved, expired, cancelled, reconciled, or otherwise concluded.

108.2 Pending status does not imply successful completion.

109.1 Records relating to duplicate or suspected duplicate transactions may be retained to establish the sequence and outcome of events.

110.1 Refunded transaction records may be retained for financial, accounting, audit, tax, and dispute purposes.

111.1 Cancelled service records may remain where necessary to establish the history and reason for cancellation.

112.1 Where StampMitra facilitates legal-document-related services, historical transaction records may require extended retention.

112.2 The applicable Service Terms and law determine the relevant retention requirements.

113.1 Where necessary, StampMitra may retain document version or transaction history to establish the sequence of changes.

114.1 Electronic signature audit information may be retained as necessary to establish the integrity and history of the signing process.

115.1 e-Stamp transaction records may be retained as necessary to establish issuance, status, correction, cancellation, or other relevant events.

116.1 Verification audit records may be retained where necessary to establish when a verification request was made, processed, completed, rejected, or otherwise concluded.

117.1 Documentation access information may be retained for security, performance, analytics, or operational purposes.

117.2 Documentation content itself is governed by the applicable API Documentation & Developer License Terms.

118.1 Commercial records may include:

• (a) plans;
• (b) subscriptions;
• (c) orders;
• (d) quotations;
• (e) invoices;
• (f) credits;
• (g) adjustments;
• (h) commercial communications; and
• (i) negotiated terms.

118.2 Such information may be retained for contractual and accounting purposes.

119.1 Enterprise customers may be subject to separate retention provisions under an Enterprise API Agreement or Order Form.

119.2 In the event of an express contractual retention period, that period shall apply to the relevant information.

120.1 Where this Schedule conflicts with a mandatory legal requirement, the legal requirement prevails.

120.2 Where this Schedule conflicts with an executed DPA concerning processor-held Developer Data, the DPA prevails to the extent of the conflict.

120.3 Where an Enterprise Agreement expressly establishes a different retention requirement, the executed agreement prevails to the extent legally permitted.

120.4 General platform policies remain applicable to matters not specifically addressed by a negotiated agreement.

121.1 StampMitra may review this Schedule periodically.

121.2 Reviews may consider:

• (a) legal changes;
• (b) regulatory developments;
• (c) security risks;
• (d) infrastructure changes;
• (e) new services;
• (f) new data categories;
• (g) deletion capabilities; and
• (h) operational experience.

122.1 Retention periods may be changed where reasonably necessary.

122.2 Changes may be made because of legal, security, operational, contractual, technical, or business requirements.

122.3 Where a change materially affects a contractual commitment, applicable notice or contractual procedures shall apply.

123.1 Employees, contractors, Developers, and service providers must not extend retention periods outside approved requirements without appropriate authorization.

124.1 Deletion processes may be automated, manual, scheduled, event-driven, or a combination of these mechanisms.

124.2 Automated deletion systems may be subject to reasonable safeguards against accidental deletion.

125.1 Exceptions to standard retention may be documented where appropriate.

125.2 Exceptions should identify:

• (a) the affected information;
• (b) reason for exception;
• (c) applicable authority;
• (d) expected duration; and
• (e) review or release condition.

126.1 Retained information remains subject to applicable security controls.

126.2 Retention does not authorize unrestricted access.

126.3 Security controls may include access restriction, monitoring, authentication, authorization, encryption or equivalent protections, and other appropriate safeguards.

127.1 During a security incident, StampMitra may preserve relevant information to support:

• (a) investigation;
• (b) containment;
• (c) remediation;
• (d) forensic analysis;
• (e) notification;
• (f) legal compliance; and
• (g) prevention of recurrence.

128.1 Following completion of an incident, information no longer required for security, legal, audit, or operational purposes may return to ordinary retention and deletion processes.

129.1 Information relating to a personal data breach or security incident may be retained for legal, regulatory, forensic, remediation, and audit purposes.

130.1 StampMitra may maintain records demonstrating compliance with this Schedule.

130.2 Audit records should not unnecessarily reproduce the underlying personal data where metadata or other evidence is sufficient.

131.1 Retention of information does not reduce confidentiality obligations.

131.2 Confidential information shall remain subject to applicable contractual and security protections.

132.1 StampMitra does not guarantee that deletion from every system, replicated environment, cache, backup, external service, or legally preserved record will occur simultaneously.

132.2 Deletion shall be carried out according to the applicable technical, legal, and operational lifecycle.

133.1 Except where required by law or necessary for legitimate legal, security, accounting, contractual, or other recognized purposes, StampMitra does not intend to retain personal information indefinitely.

134.1 Developers should review their own retention obligations before integrating StampMitra APIs.

134.2 Developers should establish appropriate deletion and archival controls for data received from StampMitra.

134.3 Developers should not represent that StampMitra retention periods automatically satisfy the Developer's own legal obligations.

135.1 Questions regarding this Schedule may be directed to:

Legal Team

BANI GLOBAL INDUSTRIES LLP

Email: [email protected]

135.2 Requests concerning personal data should include sufficient information to allow the relevant account, transaction, or data category to be identified.

136.1 StampMitra may update this Schedule from time to time.

136.2 Updates may be made to reflect:

• (a) changes in applicable law;
• (b) regulatory requirements;
• (c) technical architecture;
• (d) service changes;
• (e) security requirements;
• (f) data-processing practices; or
• (g) operational requirements.

136.3 The applicable version shall be identified by its version and effective date.

137.1 If any provision of this Schedule is determined to be invalid, unlawful, or unenforceable, the remaining provisions shall continue to apply to the maximum extent permitted by law.

138.1 Failure to enforce any provision of this Schedule does not constitute a waiver of that provision.

139.1 This Schedule shall be interpreted consistently with the applicable laws of India.

139.2 Nothing in this Schedule excludes any mandatory statutory right, obligation, remedy, or regulatory requirement.

140.1 Nothing in this Schedule is intended to restrict any mandatory right available to a Data Principal or other person under applicable law.

140.2 Where applicable law requires deletion, correction, access, restriction, portability, or another data right, StampMitra shall process the request according to the applicable legal framework.

141.1 The StampMitra API Security Policy governs security controls applicable to retained information.

141.2 Where security requirements justify extended retention, such retention shall remain subject to applicable purpose and legal limitations.

142.1 This Schedule does not establish an uptime commitment, recovery-time commitment, or service-level guarantee.

142.2 Service continuity and availability are governed by the applicable API SLA & Service Availability Policy and commercial agreement.

143.1 Billing, refund, credit, tax, accounting, and payment records shall be handled according to the Billing, API Credits & Refund Policy and applicable law.

144.1 Verification, e-Stamp, e-Sign, and legal-document-related information may be subject to additional retention requirements under the applicable Verification, e-Stamp & e-Sign Service Terms.

145.1 Retention involving external systems, service providers, or Authorized Underlying Service Providers is also subject to the StampMitra Third-Party & Underlying Services Policy.

146.1 Nothing in this Schedule requires StampMitra to disclose confidential commercial information concerning underlying service relationships, infrastructure arrangements, routing logic, provider contracts, or other confidential architecture.

• Policy Name: StampMitra Developer Data Retention & Deletion Schedule
• Policy Number: 14 of 19
• Version: 1.0
• Status: FINAL — PUBLISHED POLICY
• Effective Date: 05 October 2026
• Last Updated: 05 October 2026
• Operator: BANI GLOBAL INDUSTRIES LLP
• Prepared by: Legal Team, BANI GLOBAL INDUSTRIES LLP
• Legal Contact: [email protected]

148.1 This Developer Data Retention & Deletion Schedule constitutes the official retention and deletion framework of the StampMitra Developer Platform as of its effective date.

148.2 This Schedule is intended to establish a controlled and auditable approach to retention, deletion, anonymisation, archival, preservation, and restriction of information.

148.3 The absence of a fixed number of days for a particular data category does not authorize indefinite retention.

148.4 Retention shall remain subject to applicable law, contractual requirements, security considerations, legitimate operational requirements, and the specific purpose for which the information is processed.

148.5 StampMitra may revise this Schedule as its services, infrastructure, legal requirements, and data-processing practices evolve.