CMA Tax Companion (CTC) is a direct-taxation intelligence platform built for Indian CA, CMA, and tax practitioners. It exists to make professional tax work faster without asking the practitioner to trade away the one thing their practice cannot afford to lose: defensibility. Every answer CTC produces is grounded in a curated curated legal sources, carries a citation to its statutory source, and is separated — visibly and architecturally — from any figure that must be computed rather than retrieved.

This document explains, in verifiable terms, how CTC is designed to operate within India’s data-protection and cyber-security regime, how its architecture forecloses the failure modes that make AI unsafe for regulated advisory work, and where the professional’s own responsibilities begin. It is written to be read by a compliance officer, a security reviewer, or a practising CA deciding whether the platform is safe to place client data into — not as a marketing claim, but as evidence.

CTC’s governing priority is fixed and non-negotiable: Compliance precedes Accuracy, Accuracy precedes Auditability, Auditability precedes Optimization, Optimization precedes Speed. When these tensions arise, they are always resolved upward. A faster answer that skips source validation does not ship. An answer without a citation is not a valid answer.

General-purpose AI is unsuitable for statutory tax work for three structural reasons: it will state a confident answer with no source, it will invent a citation that looks real, and it will perform arithmetic that cannot be reproduced or audited. In a domain where a single wrong figure or a superseded provision can trigger a notice, a penalty, or professional liability, each of these is disqualifying.

CTC is engineered so that none of these failure modes can reach the practitioner:

• It cannot answer from memory. If the Knowledge Graph does not contain the source, the system declines and says so, rather than improvising.
• It cannot cite what it did not retrieve. Every citation is independently verified against the actual retrieved evidence before the answer is released.
• It does not compute statutory figures with a language model.Tax computation is deterministic and reproducible; the AI’s role is limited to retrieval, explanation, and citation.

These are not settings that can be relaxed for convenience. They are the load-bearing controls described in Sections 4 and 5.

CTC operates within a defined and current set of Indian obligations. The platform is designed to the standard each imposes, and to the practitioner’s role within it.

Digital Personal Data Protection (DPDP) Act, 2023 and DPDP Rules, 2025

India’s comprehensive data-protection framework is in force, with its operational Rules notified on 13 Nov 2025 and rolling out on a staggered timeline: the Data Protection Board of India is already operational; consent-manager provisions commence 13 Nov 2026; and the substantive obligations — lawful processing, notice and consent, data-principal rights, security safeguards, and breach notification — become fully enforceable on 13 May 2027. CTC treats the May 2027 standard as its design target today rather than a future deadline. Under this framework the practitioner (or their firm) is ordinarily the Data Fiduciaryfor their clients’ personal data, and Intime acts as a Data Processoron the practitioner’s instructions — a distinction that governs the shared-responsibility model in Section 9.

CERT-In Directions, 2022

CTC maintains security logs within Indian jurisdiction for the required rolling retention window and is architected to support incident reporting within the prescribed reporting timeline, synchronised to a reliable time source.

Professional standards (ICAI / ICMAI)

Certain acts are reserved by law to a qualified professional and cannot be automated. Signing of Form 3CA / 3CB / 3CD, DSC-authenticated return filing, and final certification of a tax computation remain the exclusive act of the certifying professional. CTC assists; the professional certifies. This boundary is enforced structurally, not merely in the interface (Section 6).

Income-tax statute (IT Act 1961 and IT Act 2025)

CTC’s source library is built on enacted statutory text, with supersession chains and effective dates tracked so that superseded provisions are never returned as a primary source. Provisions are verified against enacted text — never drafts or press releases.

CTC’s entire compute and storage footprint for client tax data is confined to the AWS Asia Pacific (Mumbai) region, ap-south-1. This is a deliberate architectural constraint, not a deployment default.

• In-region processing. All persistent stores, retrieval indexes, caches, and audit records holding client data reside in-region.
• In-region inference. Language-model inference for any request carrying client tax data is routed to a regional model endpoint within ap-south-1. Cross-region inference routing that could move compute outside India is explicitly not used for prompts containing client data — a distinction that a generic “hosted in India” claim does not capture, and one that materially affects data-locality compliance.
• Controlled egress. The platform is designed so that client tax data does not leave the India-region trust boundary. Where any model provider outside the primary in-region path is ever used, statutory identifiers and identifying figures are masked before the payload leaves the boundary, and the mapping to real values never leaves the platform (Section 6).

CTC’s answer pipeline is designed so that unverifiable content cannot reach the practitioner as fact. The controlling principle is a hard separation between what is computed and what is retrieved and explained.

Deterministic computation, never model arithmetic

Every statutory figure — tax liability, depreciation, MAT/AMT, regime comparison, interest and penalty — is produced by version-controlled calculation logic, not by a language model. Each computation emits an auditable trace of the inputs, rates, sections, and intermediate steps that produced the number, so a reviewer can reconstruct exactly how a figure was derived. Machine-learning models, where used, score risk and detect patterns only; they never determine a liability or an eligibility.

Retrieval-grounded explanation

For advisory and explanatory answers, CTC retrieves from its own Legal Knowledge Base — statute, rules, notifications, circulars, and precedent — using a hybrid of semantic and keyword retrieval. The model drafts only from what was retrieved. It is not permitted to introduce a legal claim from its own training.

The Evidence Gate

Before any drafted answer is released, every citation it contains is independently checked against the actual retrieved evidence. Claims that verify are marked accordingly; claims whose citation cannot be confirmed are stripped and routed to human review rather than silently trusted or silently deleted. This is a hard gate, not a best-effort filter: if the retrieved context does not support the answer, the system declines with a clear message rather than fabricating one.

Visible distinction

In the interface, a computed figure and an AI-drafted narrative are presented as visually distinct elements, so a practitioner can always see at a glance which part of an answer is a reproducible computation and which part is a cited, gated explanation.

Determinism for audit

Production inference runs at a fixed, deterministic setting so that the same question against the same evidence reproduces the same answer — a prerequisite for audit and for professional reliance.

CTC applies defence-in-depth across every layer that touches client data. The controls below are the ones a security reviewer will most commonly need to confirm.

• Encryption everywhere. Data is encrypted at rest under managed keys and in transit under TLS across every store and service boundary.
• Tenant isolation.Client and firm data is isolated at the database layer through enforced row-level security, so one practitioner’s or firm’s data cannot be retrieved in another’s context. Isolation is enforced server-side; a client-supplied identity or role is never trusted on its own.
• Access control. Role-based access (practitioner / CA / reviewer / administrator) with multi-factor authentication and SSO support governs who can see and do what.
• Secrets and key management. Credentials and provider keys are held in a managed secrets store with rotation; keys are never embedded in code or configuration.
• Deterministic masking on any external path. Statutory identifiers (PAN, TAN, GSTIN, IFSC, account numbers) follow fixed formats and are masked by deterministic pattern-matching — not a probabilistic classifier — before any payload could reach a provider outside the primary in-region trust boundary. The token-to-value mapping is held only in memory for the life of the request and is never transmitted.
• The statutory-signing boundary is enforced at the service layer. Any output that feeds a signed form passes through a mandatory professional-review state that the interface cannot bypass. A UI gate alone is not treated as sufficient for a compliance-grade control.

Auditability is a first-class product feature, not an afterthought. For every answer, CTC records an immutable log capturing the query, the identifiers of the exact evidence chunks retrieved, the model version used, the response returned, the citations attached, and the Evidence Gate outcome. This gives a complete, queryable record of which model produced which claim and whether that claim was independently verified — the standard any tax-advisory product must meet under professional and regulatory scrutiny.

Retention is layered to satisfy each obligation at its own horizon: security logs are retained within India for the CERT-In rolling window; logs and personal data are retained for at least the one-year minimum the DPDP Rules prescribe for detecting and remediating unauthorised access; and CTC’s own professional audit trail is retained for no less than eight years, consistent with the record-keeping horizons of tax practice.

CTC is built to support the practitioner’s breach-notification obligations, not to obscure them. Continuous threat detection and centralised monitoring run across the platform, and the incident posture is designed to support the two-tier breach reporting the DPDP framework requires — to the Data Protection Board and to affected individuals — as well as the CERT-In reporting timeline. Because the practitioner is ordinarily the Data Fiduciary, the platform’s role is to detect, contain, evidence, and inform promptly enough for the practitioner to meet their own reporting duties.

Compliance is a partnership. This white paper states plainly what CTC provides and what remains the practitioner’s own duty, because a blanket “we are fully compliant” claim would be neither accurate nor useful.

In the interest of accuracy, CTC states its boundaries as clearly as its capabilities.

• Direct tax only.CTC’s intelligence layer covers Income Tax, Corporate Tax, Capital Gains, STT, MAT, and AMT. Indirect taxes (GST, Customs, Excise) are outside the scope of the platform’s AI and retrieval paths.
• Assistance, not advice or certification. CTC is a decision-support tool for qualified professionals. It does not provide legal or financial advice, and it does not and cannot replace the judgement or the statutory certification of a qualified CA, CMA, or tax professional.
• Forward-looking statements.Regulatory timelines and control implementations described here reflect the framework as of the effective date. Where an obligation commences on a future date, CTC’s design target is that date, and this document is revised as the framework evolves.
• Verification. Users should validate the regulatory specifics in this document against the enacted statute and official notifications, and against their own professional and legal counsel, before relying on them.