Government & Public Sector

Aadhaar authentication involves: 1) UIDAI - issues Aadhaar, maintains CIDR (Central Identities Data Repository), 2) AUA (Authentication User Agency) - entities using auth services like banks, 3) ASA (Authentication Service Agency) - provides secure connectivity to CIDR, 4) KUA (KYC User Agency) - can retrieve eKYC data. Authentication types: OTP (via Aadhaar-linked mobile), biometric (fingerprint/iris), face auth. Security: encrypted PID block, device registration, audit trails. Virtual ID provides privacy by masking actual Aadhaar.

GST invoice matching: Supplier files GSTR-1 with B2B invoice details → Auto-populates in buyer's GSTR-2A/2B → Buyer claims ITC based on matched invoices. Challenges: 1) Timing mismatch - supplier delays GSTR-1, buyer can't claim ITC, 2) Invoice details mismatch - GSTIN typos, wrong invoice numbers, 3) Fake invoices for ITC fraud, 4) Large data volumes - millions of invoices monthly. Solutions: Fuzzy matching for minor errors, e-invoicing mandates real-time reporting, ML-based fraud detection, GSTR-2B is now statement of ITC (view-only).

DBT architecture: 1) Scheme portals (PM-KISAN, MGNREGA) maintain beneficiary registries, 2) Aadhaar seeding links Aadhaar to bank accounts via NPCI mapper, 3) PFMS (Public Financial Management System) manages government treasury and payments, 4) NPCI's Aadhaar Payment Bridge System (APBS) routes payments to Aadhaar-linked accounts, 5) Banks credit beneficiary accounts. Key features: Deduplication via Aadhaar eliminates ghosts/duplicates, real-time payment tracking, failed transaction handling. Scale: ₹28+ lakh crores transferred to 100+ crore beneficiaries.

Architecture considerations: 1) Single Sign-On with Aadhaar/DigiLocker for unified identity, 2) Service catalog with workflow engine for diverse services, 3) Document verification via DigiLocker APIs, 4) Multi-channel (web, mobile, kiosk, CSC), 5) Asynchronous processing for document verification and approvals, 6) Notification service (SMS, email, push), 7) Grievance management integrated. Tech stack: API gateway, microservices, event-driven architecture (Kafka), caching (Redis), search (Elasticsearch). Non-functionals: Accessibility (GIGW guidelines), vernacular support, offline capability, disaster recovery.

E-invoicing: Businesses generate Invoice Registration Number (IRN) from Invoice Registration Portal (IRP) before issuing B2B invoices. Flow: 1) Business generates invoice in ERP, 2) JSON payload sent to IRP with hash, 3) IRP validates, generates IRN and QR code with digital signature, 4) Signed invoice returned, 5) Auto-populated to GST system (GSTR-1) and e-way bill. Technical: REST APIs for integration, asymmetric encryption, NIC as IRP operator, IRN is hash of GSTIN+DocType+DocNo+FY. Benefits: Real-time reporting, reduced fake invoices, automated compliance. Threshold: Mandatory for turnover >₹5 crore.

Government security requirements: 1) Data Classification - public, internal, confidential, top secret, 2) Network security - dedicated NICNET, air-gapped systems for sensitive data, 3) PKI infrastructure for digital signatures (CCA hierarchy), 4) HSM for key management, 5) Multi-factor authentication (Aadhaar biometric + OTP), 6) Encryption at rest and transit, 7) CERT-In compliance for incident reporting, 8) Regular VAPT and security audits, 9) Data localization for sensitive government data, 10) Access control with role-based permissions. Standards: ISO 27001, GIGW (guidelines for government websites), STQC certification.

DigiLocker architecture: 1) Issuer APIs - government departments push issued documents (driving license, Aadhaar, certificates), 2) Citizen locker - personal cloud storage linked to Aadhaar, 3) Requester APIs - verifying agencies fetch documents with citizen consent. Flow: Department issues certificate → Pushes to DigiLocker with citizen's Aadhaar → Citizen views in DigiLocker app → Shares URI with requester → Requester verifies authenticity from issuer. Key features: Documents are verified at source (no fake documents), consent-based sharing, 6B+ documents stored, 150+ issuer departments. Integration: OAuth-based consent, XML digital signatures, URI-based document references.

Account Aggregator (AA) enables consent-based financial data sharing: 1) FIP (Financial Information Provider) - banks, mutual funds, insurance holding user data, 2) FIU (Financial Information User) - lenders, wealth managers requesting data, 3) AA - consent manager, doesn't store data, only routes requests. Flow: User links accounts on FIP → FIU requests data via AA → User approves consent on AA app → AA fetches encrypted data from FIP → Delivers to FIU. Technical: Data encrypted end-to-end (FIU's public key), AA can't read data, consent artifact with purpose/duration, ReBIT standards. Use cases: Instant loans (GST data), wealth aggregation, insurance underwriting. Enablers: Data Empowerment and Protection Architecture (DEPA).