Managing crypto tax compliance for multiple clients means handling dozens, sometimes hundreds, of exchange API keys across different platforms. While API access makes transaction collection faster and more accurate, it also places your firm in control of highly sensitive financial information. The moment a client shares an exchange API key and your firm uses it to pull transaction history, you begin processing personal financial data under Indian law. Without a structured system for storing, organising, and controlling access to those credentials, your practice is exposed to significant operational and regulatory risk.
That exposure has a precise cost. Under the Digital Personal Data Protection Act, 2025, a firm that fails to implement appropriate technical safeguards against a personal data breach faces a penalty of up to INR 250 crore. A separate penalty of up to INR 200 crore applies if the breach is not reported to the Data Protection Board within 72 hours of becoming aware of the breach, or within such longer period as the Board may allow on a request made in writing on this behalf. Neither figure accounts for the concurrent ICAI disciplinary action that follows a breach of client confidentiality under Clause (1), Part I of the Second Schedule of the Code of Ethics.
This guide explains how CA firms can build a secure process for managing client API keys across a growing practice. It covers how to receive client API keys securely, how to store and organise them across multiple engagements, how to scope internal access, how to rotate and revoke keys, and how to respond when a breach occurs. Every recommendation is anchored to the professional obligation it satisfies.
Key Takeaways
- A CA storing and using client exchange API keys is a Data Fiduciary under the DPDPA 2023, so technical safeguards apply.
- Failure to implement required safeguards can attract a penalty of up to INR 250 crore; failure to report a breach within 72 hours can attract an additional INR 200 crore penalty.
- Mishandling client API credentials can constitute professional misconduct under Clause (1), Part I of the Second Schedule of the Code of Ethics. Only read only API keys should be used; trading or withdrawal permissions should never be requested or retained.
- Revoke keys at the exchange level when access is no longer required. Removing a key from the firm’s records does not deactivate it.
Why Holding Client API Keys Is a Professional and Legal Risk for Indian CAs?
Indian CAs have always held sensitive client information. Bank statements, PAN details, financial records, confidentiality around all of these is governed by the ICAI Code of Ethics. Exchange API keys, however, sit in a different position: they are not just documents to be filed, but active credentials that grant live access to a client’s exchange account. That distinction is what creates the layered liability a CA firm may not have anticipated.
Data Fiduciary Status Under DPDPA 2023
Many CA firms view exchange API keys as a convenient way to collect crypto transaction data. However, once your firm receives a client’s API key and instructs it to pull transaction data from an exchange, you are determining both the purpose and the means of processing personal data.
Under the Digital Personal Data Protection Act, 2025, this automatically makes your firm a Data Fiduciary. The resulting obligations are mandatory, not optional, and include secure storage, purpose-limited retention, and breach notification within 72 hours of becoming aware of the breach, or within such longer period as the Board may allow on a request made in writing on this behalf.
Confidentiality as a Fundamental Duty Under the ICAI Code of Ethics
Managing client API keys is not only a technology responsibility but also a professional obligation. Every credential you receive forms part of the confidential information entrusted to your firm during the engagement and must be protected accordingly.
Clause (1), Part I of the Second Schedule of the Code of Ethics requires every CA to respect the confidentiality of all information acquired through professional relationships. Disclosure to any third party without proper authority constitutes a breach, regardless of whether it was intentional. The obligation also continues after the engagement ends, meaning a CA retaining a client’s credentials beyond the filing period, without explicit written authorisation, remains in continuous breach of the clause.
The Concurrent Penalty Structure a CA Firm Cannot Ignore
A compromised client API key can expose your firm to multiple regulatory proceedings at the same time. Resolving one authority’s action does not prevent or delay proceedings initiated by another, making strong access controls and credential management essential.
DPDPA 2023 penalties are assessed by the Data Protection Board of India, while ICAI disciplinary action is pursued by the Institute’s Disciplinary Directorate under the Second Schedule of the Chartered Accountants Act, 1949. A CA firm that suffers a credential breach faces both tracks simultaneously, with no mechanism to resolve one before the other. That is the architecture of liability a CA practice operates within when it stores client API keys without a formal security system.
Where Does Security Failure Actually Begin in a CA Firm?
Many CA firms still manage API keys using workflows designed for documents rather than live credentials. Because API keys remain active until revoked at the exchange, small process gaps can create significant security risks. The following are the most common weaknesses firms should address.
The Insecure Handoff Over WhatsApp and Email
When a CA requests a client’s API key, it is usually shared through WhatsApp or email. This immediately creates multiple copies of the credential across the client’s device, the CA’s device, the messaging platform’s servers, and, where enabled, third-party cloud backups.
WazirX’s official API documentation states that if API keys are accidentally shared with anyone, they must be deleted immediately and a new pair generated. Sharing keys through WhatsApp is therefore not simply an alternative communication method, it is a security failure before the key even reaches the firm.
Plain-Text Storage in Shared Spreadsheets
Once received, API keys are often entered into a shared spreadsheet containing credentials for multiple clients. Everyone involved in crypto tax engagements can usually access the same file, regardless of whether they need every client’s credentials.
The spreadsheet provides no audit trail showing who viewed, copied, downloaded, or forwarded an API key. PayPro Global’s API key management standards are explicit that keys must be stored using encryption, not protected only by file-level passwords applied to a shared document.
No Access Scoping Across the Team
Many firms keep all client API keys in a single shared repository that every team member can access. As a result, a first-year associate working on two clients may hold the same access to credentials as the principal managing the firm’s entire client portfolio.
If a laptop is compromised, a phishing attack succeeds, or an employee leaves the firm, every stored credential is exposed. This is not a matter of trusting employees; it is a structural weakness that expands the blast radius of a single incident to the firm’s complete client base.
Orphaned Keys After Engagements End
When a client changes CAs, stops filing returns, or does not continue the engagement, the API key stored by the firm is often never removed. However, the exchange continues to treat that credential as fully active unless it is explicitly revoked.
The key continues providing read access until the client logs into the exchange and deletes it, something most clients will never do unless instructed. These orphaned keys are not inactive records, they remain live credentials with no legitimate holder while sitting unmonitored in the firm’s files.
How to Verify, Accept, and Handle Client API Keys Correctly?
Before storing or managing client API keys, verify that the key has the correct permission scope. The permission level is the first security control because an over-permissioned key remains a risk regardless of how securely it is stored. The following steps explain how CA firms should verify, accept, and handle client API keys correctly.
Read-Only Access: The Only Permission a CA Requires
A read-only API key allows a connected system to retrieve transaction history, account balances, and related data. It cannot place trades, transfer assets, or initiate withdrawals. For crypto tax computation, this is the complete scope of access a CA requires.
Requesting, accepting, or retaining a key with trading or withdrawal permissions creates unnecessary risk. It has no professional basis, and no client mandate can justify giving a CA firm capabilities beyond those needed for tax compliance.
How to Verify the Permission Level Before Accepting a Key?
Clients generate their API keys before sharing them, but they may not always configure the permissions correctly. Before accepting any key, verify that only the required read permissions are enabled and all unnecessary permissions remain disabled.
For example:
- On WazirX, newly generated keys are read-only by default. SPOT trading access requires the client to explicitly enable it.
- On Binance, instruct the client to create a dedicated tax-only key with only the read permission selected and all other toggles disabled.
- On CoinDCX, read-only access to orders and transaction history is the correct configuration for tax integration purposes.
This verification takes only a few minutes and removes the most fundamental security exposure before the key enters the firm’s systems.
What to Do When a Client Shares an Over-Permissioned Key?
If a client shares a key with trading or withdrawal permissions enabled, do not store or use it. Instead, ask the client to delete the key from their exchange account immediately and generate a replacement with only read permissions enabled.
The replacement key should be transmitted through the firm’s established secure channel, and the instruction should be documented in the client file. Accepting an over-permissioned key, even if you intend to use only its read functions, means the firm possesses credentials with capabilities it has no professional justification for holding.
How Indian CAs Can Manage API Keys Across Multiple Clients?
A single client’s API key can be managed with reasonable care even without a formal system. Fifteen clients, across multiple exchanges, with a team of associates rotating through engagements, that is where informal habits break down. The controls below are not aspirational best practices. Each one addresses a specific failure point that the previous section identified in the typical CA firm’s workflow.
Establish a Secure Receipt Channel for Every Client Onboarding
Every security process begins with how client API keys enter your firm. Instead of allowing each client to share credentials through their preferred method, establish one encrypted channel for every engagement and apply it consistently across all onboardings.
Acceptable options include a password manager with an encrypted share link, where the client uses the link once, the key lands directly in the firm’s vault, and the link expires automatically. A dedicated client portal with encrypted file transfer is another suitable option. The key must never pass through a channel that stores it in plain text on a third-party server. Email inboxes and messaging apps do not meet this standard.
Store Every Key in an Encrypted Vault With Per-Client Entries
Once received, every client’s API credentials should be stored in a dedicated secret management tool or a team-plan password manager that encrypts data at rest. The encryption standard should be AES-256, the same standard referenced in PayPro Global’s API key management guidance and used by KoinX for all stored user data.
Each client should have a separate vault entry containing:
- The API key and API secret
- The exchange the key belongs to
- The permission level confirmed at the time of receipt
- The date the key was received and by whom
- The engagement period it covers
- The planned revocation date
No two clients’ credentials should share a single entry. This structure simplifies access management, improves auditability, and allows each client’s credentials to be revoked independently whenever required.
Apply Role-Based Access Controls Scoped to Client Assignments
Access to client API keys should always be based on current responsibilities, not job titles alone. Restricting access to only those working on a particular engagement reduces unnecessary exposure while ensuring team members can perform their assigned work efficiently.
A three-tier access model works effectively. The principal holds master vault access and provisions or revokes team permissions. Managers hold access only to clients within their portfolio. Associates receive access solely to their active assignments, and that access is revoked immediately when they are reassigned or leave the firm.
When responsibility transfers between associates, remove the departing associate’s access before granting access to the incoming associate. This follows the principle of least privilege, where every person receives only the minimum access their current work requires.
Log Every Access Event and Review Logs Weekly
Monitoring access is as important as restricting it. Every retrieval of a client’s API credentials should generate a timestamped log entry that identifies the individual user. Shared team logins should never be used because they prevent accurate attribution.
The firm’s principal or a designated responsible partner should review the access log weekly and look for:
- Credentials retrieved outside normal working hours
- Credentials retrieved by a staff member no longer assigned to that client
- The same credential retrieved an unusual number of times in a short window
- Access from an unrecognised device or location
These patterns do not confirm a breach. Instead, they trigger a verification conversation and, where necessary, immediate key rotation. Under DPDPA 2023, the firm must be able to demonstrate who accessed which personal data and when. A weekly log review provides the minimum evidence required to support that obligation.
Maintain a Documented Rotation and Revocation Schedule
Receiving, storing, and monitoring API keys is only part of the process. Every firm also needs a documented schedule for replacing and permanently disabling credentials. Rotation means replacing an existing key with a new one, making the old key inactive. Every active client key should be rotated at the start of each financial year filing cycle.
Revocation, which permanently deactivates a key, must happen in four specific circumstances:
- A staff member who had access to the key leaves the firm.
- A suspected or confirmed compromise occurs.
- A client engagement ends for any reason.
- The client requests it.
Revocation must always be completed at the exchange, not simply by deleting the vault entry. The client must log into their exchange account and delete the key from their API dashboard. Every revocation event should be documented with the date, the exchange, the reason, and confirmation that the client completed the deletion at the exchange end.
How To Respond When a Client API Key Breach Occurs?
A client API key breach requires an organised response, not an improvised one. Acting quickly helps limit further exposure while meeting your legal and professional obligations. Follow the steps below to contain the incident, notify stakeholders, meet regulatory timelines, and maintain the documentation required under DPDPA 2023 and ICAI requirements.
Step 1: Immediately Contain the Breach by Revoking API Keys
When a compromise is suspected through an unusual log entry, a phishing report, or a client reporting unexpected exchange activity, prioritise containment. Every API key stored in the potentially affected system should be rotated or revoked at the relevant exchange immediately.
Do not wait for the investigation to finish before taking action. The investigation should run alongside containment because every delay extends the period during which a client’s account may remain accessible. Even 1 hour spent investigating before revocation can result in 1 hour of uncontrolled access.
Step 2: Notify Every Affected Client
Inform every client whose API credentials were stored in the compromised system, even if there is no confirmation that their specific key was accessed. Early communication enables clients to secure their exchange accounts without unnecessary delay.
Your notification should explain what happened, identify the affected exchange, instruct the client to delete the existing API key and generate a new one, and outline the firm’s response. This notification fulfills the DPDPA 2023 obligation requiring a Data Fiduciary to notify affected Data Principals and supports ICAI professional conduct requirements under Clause (1), Part I of the Second Schedule of the Code of Ethics.
Step 3: Report the Breach to the Data Protection Board Within 72 Hours
Under Rule 7(2)(b) of the DPDP Rules, 2025, confirmed personal data breaches must be reported to the Data Protection Board of India within 72 hours of the firm becoming aware of the breach. The timeline begins from awareness of the incident, not from confirmation that data was actually accessed.
Waiting for complete certainty before reporting may result in missing the statutory deadline. Your report should include the nature of the breach, the data affected, the approximate number of clients involved, the containment measures taken, and the notifications already issued to affected clients.
Step 4: Document the Complete Incident Record
Maintain a detailed written record of the entire incident from detection through resolution. Record the date and time the compromise was detected, the nature of the breach, the affected clients and exchanges, the revocation actions taken and when they occurred, the client notifications issued, the report submitted to the Data Protection Board, and the investigation outcome.
This documentation serves two purposes. Under DPDPA 2023, it demonstrates the accountability expected from every Data Fiduciary. It also provides evidence to the ICAI Disciplinary Directorate that the firm handled the confidentiality incident through appropriate professional conduct rather than concealment.
Managing API key breaches manually increases the risk of delayed responses, missed compliance deadlines, and incomplete records. KoinX helps reduce these risks by providing enterprise-grade data security, role-based access controls, secure API integrations, encrypted data handling, audit trails, and other security measures that support a compliant crypto tax practice.
Traded All Year? Now File in Minutes.
Get ITR-ready tax reports now.
How KoinX Helps Indian CAs Manage Client Crypto Data Securely?
Every time a CA retrieves a client’s API key, re-enters credentials across exchange integrations, or shares access with a colleague, they create another handling event. Each interaction increases the risk of human error or unauthorised exposure. As the number of clients grows, these handling events quickly become difficult to manage through manual processes.
The practical solution is to minimize how often client credentials need to be handled while meeting the security standards under DPDPA 2023 for every Data Fiduciary. KoinX is built for this purpose. Once a client’s exchange is connected, CAs can access transaction history, tax computations, and downloadable reports through their own authenticated KoinX session, without repeatedly retrieving or re-entering the client’s credentials.
Multi-Client Portfolio Management Under One Certified Platform
Managing multiple crypto clients becomes simpler when every portfolio is available from one authenticated dashboard. Once a client’s exchange data is connected, KoinX lets you access their complete transaction history, balance records, and tax computation outputs through your own session, without retrieving or re-entering the client’s raw API credentials for every interaction. Each client’s data remains isolated within its own compartment, accessible only through your authenticated login.
ISO 27001:2022 and SOC 2 Type II Certified Infrastructure
Client data security depends on the platform you choose. KoinX is certified under the ISO 27001:2022 framework, the international standard for information security management systems, and operates under SOC 2 Type II controls, validated through third-party audits over a sustained period rather than a single point in time. For a CA acting as a Data Fiduciary under DPDPA 2023, these independently verified controls provide a defensible technical safeguard. All client data is encrypted using AES encryption and hosted on AWS, GCP, and MongoDB infrastructure.
Annual Third-Party Security Audits and Penetration Testing
Security controls must remain effective long after certification. KoinX undergoes annual third-party security audits and penetration testing to verify ongoing system integrity against real-world attack scenarios each year, rather than relying only on initial certification. For a CA processing client financial data under DPDPA 2023, this continuous testing supports the vendor due diligence expected of a Data Fiduciary when selecting systems to process personal data.
Complete Tax Reports for Every Client Without Repeated API Access
Once a client’s data is connected, KoinX allows you to generate every required report from a single authenticated session without requesting exchange credentials again. Available reports include:
Each report can be downloaded and regenerated as many times as needed within the financial year.
For Indian CAs managing multiple crypto clients who need a secure, certified environment for client data, connect your first client on KoinX and generate their complete tax report from your dashboard today.
Conclusion
An API key is not a document, it is a live credential that remains active at the exchange until explicitly revoked. Every informal habit a CA firm runs today, the WhatsApp handoff, the shared spreadsheet, the key that outlives the engagement, creates a specific liability under DPDPA 2023 and the ICAI Code of Ethics. The five controls in this guide replace those habits with a system that is both professionally defensible and practically manageable.
The fewer times a CA directly handles a raw client credential, the smaller the risk surface. KoinX reduces those handling events by giving CAs a single ISO 27001:2022 and SOC 2 Type II certified dashboard, where every client’s tax reports are generated and downloaded without re-entering their exchange credentials each time.
Frequently Asked Questions
A Client Sent Their API Key Over WhatsApp. What Should I Do Immediately?
Treat the key as compromised from the moment it was sent. Ask the client to log into their exchange account and delete that key from their API dashboard immediately. Once they confirm deletion, ask them to generate a new read-only key and share it through a secure channel your firm establishes. Delete the WhatsApp message from your device and document the incident, the original channel used, the deletion instruction given, and the date the replacement was received.
Does DPDPA 2023 Require Explicit Client Consent Before I Store Their API Key?
Yes. Under DPDPA 2023, a Data Fiduciary must obtain the Data Principal’s consent before processing their personal data. A client who voluntarily provides their API key for tax filing purposes is consenting to that specific use. Document this consent in the engagement letter, specifying what data will be accessed, how it will be stored, who within the firm will have access, and when it will be deleted. Accessing data beyond that stated purpose falls outside the consent given.
A Staff Member Has Left the Firm. Do I Need to Revoke the Client Keys They Had Access To?
Yes, and revocation must happen at the exchange, not just in the firm’s vault. Removing the departed staff member’s vault access prevents further retrieval through the firm’s system, but it does not deactivate any key they may have noted before leaving. Every client whose credentials that person had access to should be contacted, asked to delete their current key at the exchange, and asked to generate a fresh replacement for the continuing engagement.
A Client Shared a Key With Trading Permissions Enabled. Can I Use It Only for Reading Transaction Data?
No. Accepting and storing a key with trading permissions means the firm holds credentials it has no professional justification for retaining, regardless of which functions are actually used. Ask the client to delete that key from their exchange account immediately and generate a replacement with read-only permissions only. Document the instruction and the outcome in the client file. Using an over-permissioned key, even with self-imposed restrictions, creates liability the firm cannot subsequently disclaim.
How Long Can I Retain a Client's API Key After the Engagement Ends?
DPDPA 2023 requires a Data Fiduciary to delete personal data once the purpose for which it was collected has been fulfilled. An API key collected for FY 2025-26 tax filing has no legitimate purpose after that filing is complete. The ICAI Code of Ethics does not authorise indefinite retention either. Revocation at the exchange and deletion from the vault should be completed as part of the engagement closure process, documented with a date and confirmation that the client completed the exchange-level deletion.
What Is the Difference Between Deleting a Key From My Vault and Revoking It at the Exchange?
Deleting a key from the firm’s vault removes the firm’s copy of the credential. It does not affect the key’s status at the exchange, the key remains active and fully functional until the client logs in and deletes it from their API dashboard. Revocation instructions must therefore always go to the client. Only they can deactivate the key at its source. Vault deletion alone leaves the client’s exchange account carrying an active credential with no legitimate holder.
Is a Password-Protected Google Sheet Sufficient Storage for Client API Keys Under DPDPA 2023?
No. A password-protected spreadsheet is not an encrypted storage system within the meaning of DPDPA 2023’s technical safeguard requirement. File-level passwords can be bypassed, provide no access logging, and offer no granular permission control. Google Sheets can be shared or downloaded without an audit trail. DPDPA 2023 requires Data Fiduciaries to implement appropriate technical safeguards to prevent data breaches. A dedicated secret management tool with AES-256 encryption, individual authentication, and per-entry access controls meets that standard, a shared spreadsheet does not.
A Suspected Breach Occurred in Our Systems Last Week. What Are Our Reporting Obligations Now?
The 72-hour notification window under Rule 7 of the DPDP Rules, 2025 runs from the moment the firm became aware of the breach, not from when it was confirmed. If that window has passed, file the notification with the Data Protection Board immediately regardless. Simultaneously, notify every client whose credentials were stored in the affected system, revoke all potentially exposed keys at the exchange level, and document every action taken with timestamps. Consult a data protection lawyer before determining how to address the delayed notification in your submission.
