The Foreign Contribution (Regulation) Act, 2010 imposes specific, detailed and increasingly enforced requirements on every Indian organisation that receives foreign contribution: designated bank accounts, fund segregation, activity restrictions, administrative cost caps, annual reporting, prior permission or registration renewal and compliance with conditions that can change through notification.
Most social organisations comply with FCRA reactively: filing the annual return (FC-4) after the year ends, segregating accounts when the auditor identifies the requirement, documenting foreign contribution utilisation when the renewal application is due.
Reactive compliance creates three problems. First, it is expensive: reconstructing documentation, reclassifying transactions and preparing returns from incomplete records requires professional fees and management time that proactive systems would have avoided. Second, it is risky: gaps in documentation, late filings, incorrect classifications and inadvertent violations create regulatory exposure that can result in FCRA suspension or cancellation. Third, it is ineffective: compliance that is assembled after the fact cannot demonstrate the real-time governance that the regulatory framework is designed to ensure.
The FCRA Governance Architecture is a proactive system designed to make compliance demonstrable rather than retrospective: building the controls, the fund segregation, the documentation and the reporting into the organisation's operating processes so that audit-ready evidence is produced as a natural byproduct of daily operations.
The Architecture: Seven Components
1. Designated account management
FCRA requires foreign contributions to be received in a designated bank account at the State Bank of India, New Delhi, and then transferred to a designated utilisation account. The architecture: automated monitoring of the designated account, documented transfer protocols, reconciliation between receipt and utilisation accounts, and real-time tracking of the balance between received and utilised funds.
2. Fund segregation
Foreign contribution must be segregated from domestic funds at every level: separate bank accounts, separate accounting codes, separate cost centres and separate reporting. The architecture: chart of accounts designed with a primary classification by funding source (FCRA, domestic, self-generated), ensuring that every transaction is tagged to its source at the point of entry, not reclassified at year-end.
3. Administrative cost tracking
FCRA caps administrative expenditure at 20% of foreign contribution received in a financial year. The architecture: real-time tracking of administrative costs as a percentage of foreign contribution received, with automated alerts when the ratio approaches the threshold. The classification of costs between "administrative" and "programme" must be defined in policy, applied consistently and documented with evidence supporting each classification.
4. Activity compliance
Foreign contribution can be used only for the purposes for which the organisation's FCRA registration was granted. The architecture: a mapping of every programme and activity to the FCRA-registered purpose, with documented approval for each activity confirming its eligibility. New activities must be evaluated against the registration scope before funding is committed.
5. Sub-granting and downstream compliance
Organisations that sub-grant FCRA funds to implementing partners must ensure that the partners are themselves FCRA-registered and compliant. The architecture: due diligence on every sub-grantee (FCRA registration verification, compliance history, financial capability assessment), monitoring of sub-grantee utilisation and consolidated reporting that covers the entire fund flow from receipt through sub-grant to beneficiary.
6. Documentation standards
Every transaction funded by foreign contribution must be supported by documentation that can withstand regulatory scrutiny: purchase orders, competitive quotation records, approval documentation, goods receipt, invoice verification, payment authorisation and bank confirmation. The architecture: a documentation checklist for each transaction type, applied at the point of processing, with exceptions flagged and escalated rather than accepted.
7. Reporting and filing
The FC-4 annual return, the quarterly intimation of receipt (for prior permission holders), the reporting of changes in office bearers, bank accounts or objectives, and the compliance with conditions specified in the registration or renewal letter. The architecture: a compliance calendar with automated reminders, pre-populated draft returns generated from the accounting system and a review and approval workflow that ensures every filing is accurate, complete and timely.
Why Architecture Matters More Than Compliance
The regulatory environment for FCRA has tightened significantly. The 2020 amendments introduced: mandatory receipt through the SBI New Delhi designated account, prohibition on sub-granting to non-FCRA entities, reduction of the administrative cost cap from 50% to 20%, Aadhaar identification requirements for office bearers and mandatory renewal every five years with compliance scrutiny.
Enforcement has intensified. FCRA registrations have been cancelled or suspended for: failure to file the annual return, incorrect utilisation of foreign contribution, inadequate fund segregation, non-compliance with conditions of registration and failure to maintain proper accounts.
In this environment, reactive compliance, assembling documentation and correcting classifications at year-end, creates unacceptable regulatory risk. A single documentation gap, a single misclassification, a single late filing can trigger scrutiny that is difficult and costly to resolve.
The FCRA Governance Architecture converts compliance from a periodic exercise into a continuous operating discipline. The controls operate in real time. The documentation is generated at the point of transaction. The reporting data is available continuously, not assembled retrospectively. The organisation can demonstrate compliance at any point in time, not just at the filing date.
In Northrop Management Private Limited's governance advisory work with social organisations, FCRA architecture design is approached as a systems problem rather than a compliance problem. The question is not "how do we file the FC-4?" It is "how do we build an operating system that makes every FCRA requirement demonstrable at every moment?"
Ashish Chaudhary, frames the governance principle directly: "Governance should make compliance demonstrable rather than retrospective. An organisation that builds FCRA compliance into its operating processes produces audit-ready evidence as a byproduct of its daily work. An organisation that assembles compliance evidence after the year ends is hoping that nothing was missed. In the current regulatory environment, hoping is not a governance strategy."
Questions for the Governing Body
- Are our FCRA funds segregated from domestic funds at the bank account level, the chart of accounts level and the reporting level?
- Can we produce our administrative cost ratio in real time, or only at year-end?
- For every transaction funded by foreign contribution, do we have the complete documentation chain (approval, procurement evidence, receipt verification, payment authorisation) at the point of transaction, or do we assemble it retrospectively?
- Have we conducted due diligence on every sub-grantee's FCRA registration status and compliance history?
- If the Ministry of Home Affairs requested a compliance review tomorrow, could we produce audit-ready evidence of every FCRA requirement within one week?
Closing Implication
FCRA compliance is not a filing exercise. It is an operating system. An organisation that files accurately and on time has met the minimum. An organisation that has built the controls, the segregation, the documentation, the tracking and the reporting into its daily operations has built a governance architecture that makes compliance demonstrable at any point, not just at the filing date.
The architecture is the protection. Not the filing. Not the auditor. Not the legal advisor. The system that produces audit-ready evidence continuously, as a byproduct of operations rather than as a product of year-end effort.
