What changed in July 2026

CBDT released an updated Guidance Note and FAQs on FATCA and CRS reporting on 24 July 2026. The official Income Tax Department reference states that the guidance is meant for Reporting Financial Institutions, regulators and Income Tax Department officers, and explains reporting requirements under section 508 of the Income Tax Act, 2025, Rules 238 to 240 and Form 166 of the Income-tax Rules, 2026. It also updates the conversation for newer digital financial products, including specified electronic money products, central bank digital currencies and relevant crypto-assets.

For founders, the important question is not “Are we a bank?” The better question is “Does our product perform a financial-account, custody, investment, crypto-asset, wallet, brokerage, fund, trust or reporting-platform function that may bring us into the FATCA/CRS perimeter?” Many startups do not look like traditional financial institutions, but their product may still collect, hold, invest, transfer or report financial value in a way that requires careful classification.

FATCA is the US-origin tax transparency framework under which foreign financial institutions identify and report certain US account holders. CRS is the OECD-led Common Reporting Standard for automatic exchange of financial account information between participating jurisdictions. India participates in automatic exchange of information, and Indian reporting entities must collect, validate and report prescribed information where applicable.

Who should review this guidance now?

A pure software vendor that never opens accounts, holds assets, processes reportable financial data or controls customer onboarding may not be the reporting institution. But it may still need contractual obligations, data fields, security controls and audit trails because its bank, broker, fund or exchange clients rely on the software for FATCA/CRS compliance.

The first step is classification, not filing

Founders often jump to the filing question too early. Before asking whether Form 166 applies, classify the entity and product. Is the company a Reporting Financial Institution, a non-reporting financial institution, an active non-financial entity, a passive non-financial entity, a crypto-asset service provider, a technology processor, a payment product, a broker-like platform or something else?

Classification should be documented. If the startup concludes it is not a Reporting Financial Institution, keep the reasoning and legal review. If the classification depends on product design, update it when the product changes. A wallet that only provides technology support may differ from a wallet that stores value or enables crypto-asset transfers. A wealth dashboard may differ from a platform that executes or holds investment accounts.

Customer data fields founders should check

A FATCA/CRS-ready platform needs the right data at onboarding, not at year-end panic time. If reportable-account review applies, the system should collect and validate customer identity, tax residency, taxpayer identification number, date and place of birth where required, entity classification, controlling-person details, address, account number or identifier, account balance/value and relevant transaction or income fields.

This is not only a compliance-team issue. Product and engineering teams must design the onboarding flow, database schema, validation rules, document upload logic, exception workflow and audit log. If a customer refuses self-certification, the system should know what happens next. If tax residency changes, the platform should capture a refreshed self-certification.

• Tax residency country or countries.
• Taxpayer Identification Number or reason for non-availability.
• US indicia where FATCA is relevant.
• Entity type and controlling persons for non-individual accounts.
• Self-certification date, version and acceptance record.
• Documentary evidence and KYC linkage.
• Account balance, value or closure status where reportable.
• Relevant crypto-asset transaction or holding data where applicable.

Crypto, wallets and digital assets: why the guidance matters

Crypto platforms should pay special attention because tax transparency frameworks are moving toward visibility over relevant crypto-assets. A crypto exchange, wallet, custody provider, broker, transfer platform or tokenised-asset business should not assume FATCA/CRS is a bank-only issue. Product teams need to map whether the platform holds assets, executes transactions, intermediates transfers, records beneficial ownership, or merely provides analytics.

The founder risk is operational. If the platform starts collecting only basic KYC but later discovers it needs tax-residency, TIN and reportable transaction fields, retrofitting the system can be expensive. Customers may ignore remediation requests. Historic data may be incomplete. Annual reporting may become unreliable.

FATCA/CRS data is also privacy-sensitive data

Tax residency, TIN, account value, transaction information, passport details and controlling-person data are sensitive in a practical sense even where a statute uses its own terminology. Fintech and crypto startups should align FATCA/CRS collection with privacy notices, DPDP readiness, access controls, retention policies and vendor contracts.

Do not collect tax-residency information through an informal form and store it in a shared spreadsheet without access logs. Do not send customer lists over email to consultants without data-processing terms. Do not use production customer data in testing environments without masking. If the company is collecting data for statutory reporting, the customer notice and internal policy should say so clearly.

• Update privacy notice for tax-reporting and statutory-compliance purposes.
• Restrict access to tax-residency and TIN data.
• Encrypt exports and logs where feasible.
• Set retention and deletion rules consistent with law and audit needs.
• Check vendor contracts for confidentiality, security and breach obligations.
• Maintain breach response and regulator/customer communication workflows.

Form 166 readiness: do not wait until reporting season

The updated guidance refers to Form 166 under the Income-tax Rules, 2026. Founders should treat the form as a systems-readiness issue. If a reporting obligation applies, the required fields must be available, validated, exportable and internally approved. Manual compilation from scattered spreadsheets is a warning sign.

Contracts and vendor clauses to update

Many startups outsource KYC, wallet infrastructure, cloud hosting, analytics, tax reporting, customer support, fraud monitoring or transaction screening. If those vendors touch FATCA/CRS data, contracts must allocate responsibility. A founder should not discover during a reporting cycle that the vendor cannot provide required fields or audit logs.

• Data fields and format the vendor must support.
• Confidentiality and restricted-use obligations.
• Security controls and access logs.
• Data localisation or transfer review where relevant.
• Breach notification timelines.
• Assistance with customer correction or remediation.
• Audit rights or compliance evidence.
• Exit and data return/deletion obligations.

Founder mistakes to avoid

• Assuming FATCA and CRS apply only to banks.
• Launching a wallet, crypto or investment product without entity classification review.
• Collecting KYC but not tax residency or TIN fields where needed.
• Building onboarding flows that cannot refresh self-certifications.
• Keeping reportable data in spreadsheets outside product systems.
• Ignoring controlling-person rules for entity customers.
• Treating DPDP/privacy notice updates as separate from tax-reporting data collection.
• Waiting until annual reporting season to check Form 166 fields.
• Outsourcing KYC or reporting without vendor accountability.
• Failing to document why the company concluded it is not a reporting entity.

90-day FATCA/CRS cleanup plan for fintech and crypto founders

Self-certification workflow founders should build

Self-certification is not a PDF form hidden in onboarding. It is a product workflow. The customer should be asked clear questions, the platform should validate obvious gaps, and exceptions should route to compliance. For entity customers, the workflow should identify the entity type, whether it is active or passive where relevant, and who the controlling persons are.

Who should own FATCA/CRS inside a startup?

In early-stage fintech companies, compliance often sits informally with the founder, finance head or operations lead. That is risky for FATCA/CRS because the obligation crosses legal, product, engineering, data, support and finance. The founder should appoint a clear owner and create a small operating rhythm.

• Legal or compliance owns classification, rule interpretation and reporting calendar.
• Product owns onboarding screens, customer declarations and remediation flows.
• Engineering owns database fields, validation, exports, access control and logs.
• Finance owns filing coordination, maker-checker review and statutory evidence.
• Customer support owns customer queries and document follow-ups.
• Founder or board owns risk acceptance where the product enters a new regulated category.

This ownership should be written in an internal compliance note. If the startup raises money, investors may ask who owns regulatory compliance and whether the system is founder-dependent or process-driven.

Board note for founders entering financial-account products

If a startup is moving from a simple software product into wallets, broking, crypto custody, investment execution or treasury products, the board should record the compliance review. The note does not need to be theatrical. It should capture the product change, legal classification, reporting risk, customer-data implications, vendor dependencies, implementation owner and timeline.

A board-level record helps later diligence. It shows the company did not stumble into a regulated reporting position accidentally. It also helps finance and compliance teams obtain budget for product changes before the reporting deadline becomes urgent.

Investor diligence angle for fintech and crypto startups

Investors in regulated or compliance-heavy fintech startups will ask whether the company has mapped FATCA/CRS, PMLA/KYC, DPDP, RBI, SEBI, FIU-IND and tax-reporting obligations. A founder who says “our vendor handles it” without evidence creates concern. A founder who can show classification memo, workflow screenshots, data schema, reporting calendar and vendor obligations creates confidence.

Frequently asked questions

Sources and official references

• Income Tax Department guidance note on FATCA and CRS: https://www.incometaxindia.gov.in/w/guidance-note-on-fatca-and-crs-2
• Income Tax Department AEOI page: https://www.incometaxindia.gov.in/automatic-exchange-of-information-aeoi-
• CBDT / Income Tax Department official website: https://www.incometaxindia.gov.in/
• Digital Personal Data Protection Act, 2023, MeitY PDF: https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf
• OECD Common Reporting Standard information: https://www.oecd.org/tax/automatic-exchange/common-reporting-standard/
• IRS FATCA regulations and guidance: https://www.irs.gov/businesses/corporations/fatca-regulations-and-other-guidance

Founder takeaway

FATCA and CRS compliance is no longer something fintech and crypto founders can leave entirely to a future compliance hire. If the product touches accounts, assets, wallets, investments, tax residency or cross-border users, build classification, onboarding, reporting and privacy controls early. Retrofitting tax-transparency compliance after scale is far more painful than designing it into the product now.