#FactCheck - Viral Photos Falsely Linked to Iranian President Ebrahim Raisi's Helicopter Crash

Introduction

On September 1–2, 2026, the G20 Innovation Ministerial was held at the Carolina Inn in Chapel Hill, North Carolina. This gathering of ministers, senior officials, and high-profile technology executives marked the first sectoral ministerial of the G20 presidency held by the U.S. government this year. The two consensus documents that resulted from the meeting,  the G20 Innovation Ministerial Statement and the Carolina Principles, are expected to dictate how the largest world economies regulate AI for many years. In this post, the content of the two documents will be discussed along with their role in the larger context of the U.S. G20 presidency that will culminate in the leaders’ summit in Miami scheduled for December and the response of the tech community, allied governments, and civil society to the framework.

The U.S. Presidency and the Road to Chapel Hill

The United States assumed the rotating G20 presidency on December 1, 2025, and immediately signalled a departure from the priorities pursued by South Africa, the previous chair, whose 2025 Johannesburg summit had emphasised climate finance and debt sustainability for developing economies, a summit the U.S. ultimately boycotted. In its opening statement, the State Department announced that the American presidency would organise the year around three themes: reducing regulatory burdens on economic growth, securing affordable and reliable energy supply chains, and "pioneering new technologies and innovations". The Innovation Ministerial in Chapel Hill was the clearest single expression of that third pillar, and it was scheduled ahead of the finance ministers' meetings in Asheville and the foreign ministers' meetings in Atlanta, with the full cycle set to close at the Leaders' Summit at Trump National Doral in Miami on December 14–15, 2026.

Symbolism was deliberately built into the choice of venue. White House science and technology advisor Michael Kratsios, who chaired the ministerial, argued that North Carolina's Research Triangle and its status as home to the nation's first public university made Chapel Hill an apt backdrop for a statement about translating research into commercial and public benefit. The venue also produced the framework's name: the Carolina Principles.

The Innovation Ministerial Statement: Six Pillars

‍

The Innovation Ministerial Statement is organised around six pillars: 

pro-innovation policy frameworks; technology for opportunity and prosperity (chiefly AI adoption in public services); 

• skilled technical workforce development; 
• intellectual property policy for AI; 
• standards that support both AI-enabled standards development and standards for AI systems; and
•  industrial innovation and supply-chain resilience. 

‍

All six ideas run together in one concept: "Old-fashioned or too rigid regulatory systems can limit innovation in an unintended way," and successful policymaking, short of restricting entrepreneurial initiatives, consists of creating the type of regulatory framework which is effective and flexible. The language is also marked by sensitivity to sovereignty, stating repeatedly that countries have the right "to formulate their policies and express their sovereignty on issues of emerging technology governance" and thus make it possible for twenty countries with different legislative customs to agree upon one text.

On IP, the statement treats the copyright-AI interface as unresolved by design, noting that questions about how doctrines such as prior consent and fair-use-style exceptions apply to AI training "remain appropriately resolved through each member's established legal processes" rather than through a harmonised international rule. On standards, it frames AI itself as a tool for regulatory efficiency for comparing safety and performance data across jurisdictions and reducing duplicative testing while affirming that market competition, not government selection, should determine which AI models succeed.

The Carolina Principles: Structuring the Technology Lifecycle

Where the Ministerial Statement sets out aspirations, the Carolina Principles operationalise them across the "science and technology development lifecycle". The document is structured in three parts. The first, Advancing Discovery and Strengthening Technology Development, calls for sustained public investment in foundational research, blended public-private financing across technology readiness levels, and streamlined administrative processes for R&D funding. The second, Accelerating Validation and Commercialisation, is the most operationally specific section, endorsing regulatory sandboxes, results-based funding mechanisms, and innovation-orientated public procurement to help technologies cross the gap from laboratory to market. The third, Enabling Technology Adoption, is the section that has drawn the most political attention: it commits members to apply existing sector-specific regulatory frameworks to AI wherever possible and to reserve new rulemaking only for "novel considerations that existing legal frameworks cannot adequately address" as defined in The Carolina Principles for Emerging Technologies, 2026, Section III.

That last commitment is the crux of what commentary has called the U.S.'s "light-touch" pitch to the world. Rather than proposing a new international AI regulator, the Carolina Principles ask governments to extend the jurisdiction of existing sector regulators and  financial supervisors handling AI in finance and health authorities handling AI in medical devices and to treat novel, cross-cutting AI regulation as an exception rather than a default. Commerce Secretary Howard Lutnick announced that all twenty G20 members, including China, endorsed the framework, calling it a product of "an enormous amount of work" given the divergent starting positions in the room. The timing was pointed: the framework was finalised roughly a month after the European Union's AI Act reached its most consequential enforcement milestone, with binding obligations for high-risk AI systems taking effect on August 2, 2026,  a contrast Elon Musk, participating in the ministerial, invoked directly in criticising EU-style regulation.

Reception: Consensus Inside, Scepticism Outside

Inside the Carolina Inn, the mood among industry leaders was buoyant. In a fireside conversation with Secretary Lutnick, OpenAI's Sam Altman described AI as "incredible magic of intelligence in a bottle" while warning that continued infrastructure build-out, more data centres, and more compute would be necessary to keep costs manageable. Nvidia's Jensen Huang and Palantir's Alex Karp offered similarly optimistic assessments, and Anthropic's participation in a voluntary model-testing arrangement with the U.S. government's safety and security institute was cited by OSTP Director Kratsios as evidence that industry-government cooperation, rather than statutory mandate, could deliver trustworthy AI.

Outside the security perimeter, several hundred demonstrators, like students, faculty, and local organisers,  gathered to protest what they characterised as an unaccountable alliance between government and AI capital, chanting slogans against both the technology's labour-market effects and the data centre buildout it requires. The juxtaposition captured a tension that runs beneath the consensus text itself: a framework designed to secure the broadest possible international agreement necessarily says less about how risks Labour displacement, energy demand, and algorithmic harm will be managed than it does about how innovation will be accelerated.

Conclusion

The Carolina Principles represent a coherent and, by G20 standards, unusually specific attempt to answer a question that has vexed multilateral technology governance for a decade: how do twenty economies with incompatible regulatory philosophies agree on anything regarding AI? The answer Chapel Hill produced was to agree on process rather than on substantive limits. Whether that process-based consensus proves durable will depend on what happens between now and the Miami Leaders' Summit in December, when heads of state, rather than ministers, will decide whether to elevate the Carolina Principles into the G20's broader economic agenda or treat them as a single ministerial's contribution to a much longer conversation.

References

1. https://assets.publishing.service.gov.uk/media/6a996786f5b35599aec19180/g20-innovation-ministerial
2. https://www.commerce.gov/sites/default/files/2026-09/THE-CAROLINA-PRINCIPLES-FOR-EMERGING-TE
3. https://www.commerce.gov/news/press-releases/2026/09/g20-innovation-ministerial-concludes-conseNSUS statement
4. https://www.whitehouse.gov/releases/2026/09/g20-innovation-ministerial-concludes-with-consensus-sstatement/
5. https://www.state.gov/policy-issues/g20/feed/
6. https://g20.org/g20-united-states/
7. https://dailytarheel.com/480187/university/university-g20-event-1/
8. https://qz.com/g20-us-light-touch-ai-framework-chapel-hill-090326
9. https://explainx.ai/blog/g20-carolina-principles-ai-regulation-chapel-hill-2026
10. https://enterprisedna.co/resources/news/us-g20-carolina-principles-ai-regulation-enterprise-september-2026/
11. https://www.cnbc.com/2026/09/02/g20-innovation-ministerial-live-updates.html
12. https://fortune.com/2026/09/05/tech-ceos-ai-data-centers-g20-protests-sam-altman-nvidia-jensen-huang-palantir-alex-karp-chapel-hill-north-carolina-ai-backlash/
13. https://www.wunc.org/education/2026-09-02/protest-chapel-hill-unc-g20-innovation-technology-sam-a
14. https://www.cfr.org/articles/us-g20-presidency-narrow-agenda-2026

‍

Introduction

For most of us, UPI is part of daily routine: scan a QR code for chai, send money to family, split a bill, or pay a shopkeeper in seconds. That convenience is exactly why a message saying “UPI charges are coming” can cause confusion. Scammers can use that uncertainty through fake calls, WhatsApp messages, payment links, or edited screenshots. This blog keeps the topic simple: what MDR means, which UPI payments remain free, how scammers misuse the word “fee”, and what a reader should do when a payment request does not look right.

News in Focus: Why the “UPI Charge” Headline Needs Context

‍

‍

On 15 September 2026, the Ministry of Finance clarified the revised UPI framework. From 15 October 2026, a 0.4% MDR will apply to specified P2M transactions above ₹2,000, subject to the published conditions and caps. P2P transfers remain free, payments to merchants up to ₹2,000 remain free, and the government states that MDR is an ecosystem charge, not a customer fee. Banks are to ensure it is not passed on to customers. [1]

‍

So, What Does This Mean for an Everyday User?

‍

‍

The important distinction is between a legitimate MDR rule and a scammer’s request for money. A message saying “pay ₹99 to release your UPI transaction” is not made genuine by mentioning NPCI, a bank, a government notice, or a news report.

‍

A Related Cyber-Fraud Headline: Do Not Mix Two Different Issues

‍

‍

The supplied newspaper clipping discusses a separate cyber-fraud issue involving suspicious transactions and bank accounts linked to cybercrime. It is useful context, but it should not be read as proof that ordinary UPI users must pay a special “verification” or “release” fee. Separating the two issues helps prevent panic and misinformation.

‍

Where Scammers Use the Confusion

‍

“Pay a small fee to receive money”

A simple red flag is the demand for an upfront fee: “Your refund is ready, pay a processing fee first.” NPCI warns that scanning a QR code and entering a UPI PIN is for making a payment, not for receiving money or cashback. [2]

Fake payment success screens

Another common trick targets merchants: a fraudster shows a convincing “Payment Successful” screenshot and collects goods before the seller checks the account. In August 2026, Delhi Police reported a case involving allegedly fake or manipulated Paytm/UPI screenshots, followed by an attempt to gain access to victims’ mobile phones. [3] In September, police in Jharsuguda and Basti reported similar fake-confirmation cases; the Basti case involved a fabricated SBI YONO screenshot. [4][5]

“Your UPI is blocked because of new charges”

Scammers also borrow the language of genuine policy announcements. The caller creates urgency, claims your account is restricted, and asks you to install an app, share an OTP, approve a collect request, or transfer a small amount “for verification”. A real headline does not make an unexpected payment request genuine.

‍

The Five-Second UPI Safety Check

‍

Puse Before You Pay

‍

WHO is asking? WHAT exactly are they asking you to do? WHERE did the payment request appear? WHEN did the request arrive? WHY would you need to pay to receive money? Verify the transaction in your own bank or UPI app. Merchants should not rely on a screenshot shown by a customer. Customers should not treat a QR code, collect request, or incoming message as proof that they are “receiving” money. Read the final authorisation screen before entering the UPI PIN. NPCI says users should never share the PIN and that bank customer support will not ask for it. [6]

‍

If You Think You Have Been Scammed

‍

• Stop engaging with the suspected caller, account, or chat. Do not send another payment to “fix” the first one.
• Contact your bank or the relevant payment app using an official support channel and report the transaction.
• For financial cyber fraud in India, call 1930 as soon as possible and report the incident through the National Cyber Crime Reporting Portal. The official portal identifies 1930 as the helpline for immediate reporting of financial cyber fraud. [7]
• Keep the transaction ID, screenshots, phone numbers, messages, and dates. Do not delete useful evidence.

‍

Conclusion

‍

The safest way to understand the UPI charge discussion is to slow the headline down. Yes, a revised MDR framework has been announced for certain merchant transactions above ₹2,000 from 15 October 2026. But that does not make a P2P transfer subject to a “release fee”, and it does not make an unsolicited ₹49, ₹99, or ₹199 demand legitimate. Check the transaction type, confirm where the charge sits, verify the payment in your own app or bank account, and never disclose your UPI PIN. Digital safety is not about fearing every payment; it is about recognising when someone asks you to leave the normal payment process.

‍

Remember

‍

UPI convenience should never require blind trust. Verify the sender, verify the screen, verify the transaction.

‍

References

‍

[1] Press Information Bureau, Ministry of Finance, “UPI Continues to Remain Free for Peer to Peer Transactions and 96% of Merchant Transactions,” 15 September 2026. https://www.pib.gov.in/PressReleseDetailm.aspx?PRID=2310586

[2] National Payments Corporation of India (NPCI), “Fraud Awareness,” current guidance on fake cashback links, QR codes and UPI PIN safety. https://www.npci.org.in/fraud-awareness

[3] Hindustan Times / PTI, “Delhi Police arrest man in ₹30.81 lakh cyber fraud involving fake UPI payments,” 26 August 2026. https://www.hindustantimes.com/cities/delhi-news/delhi-police-arrest-man-in-rs-30-81-lakh-cyber-fraud-involving-fake-upi-payments-101787734051785.html

[4] The Times of India, “Two held for fake UPI payment fraud in Jharsuguda,” 11 September 2026. https://timesofindia.indiatimes.com/city/bhubaneswar/two-held-for-fake-upi-payment-fraud-in-jharsuguda/articleshow/134072823.cms

[5] The Times of India, “Basti: 2 held for fake UPI payment scam,” 13 September 2026. https://timesofindia.indiatimes.com/articleshow/134154561.cms

[6] NPCI, “UPI - Frequently Asked Questions,” UPI PIN and transaction-confirmation guidance. https://www.npci.org.in/what-we-do/upi/faqs

[7] Government of India, National Cyber Crime Reporting Portal, financial cyber fraud reporting guidance and helpline 1930. https://www.cybercrime.gov.in/

[8] Moneycontrol, “Don't trust the screenshot: How to spot a fake UPI payment,” 6 August 2026. https://www.moneycontrol.com/news/business/personal-finance/don-t-trust-the-screenshot-how-to-spot-a-fake-upi-payment-13996275.html

Image note: Both visuals were supplied by the requester. Figure 1 was cross-checked against the Ministry of Finance/PIB clarification cited in Reference [1].

‍

Introduction

For years, Indian companies could get away with vague privacy promises. That window closed on 13 November 2025, when the government notified the Digital Personal Data Protection Rules, giving teeth to the broad principles Parliament had passed back in 2023 under the DPDP Act. The Rules turned soft commitments into specific, auditable duties, and a lot of organisations are only now realising how much that actually changes.

Start with Section 8(4). It requires every Data Fiduciary to put "appropriate technical and organisational measures" in place. Most readers skim past "organisational" and focus on the technical half, but that's a mistake, because the word is doing real work. It's asking for defined roles, written policies, staff training, and someone actually watching whether any of it holds up over time, not just firewalls and encryption keys. Section 8(5) goes further, demanding reasonable security safeguards against breaches, and Rule 6 spells out exactly what that phrase means in practice: encrypt data at rest and in transit, restrict access on a need to know basis, require multi factor authentication, log and monitor activity, run regular vulnerability checks, bind your data processors contractually to the same standard, and keep relevant logs for at least a year.

Then there's Rule 7, and this is where the clock starts running. Once a Data Fiduciary becomes aware of a breach, the Data Protection Board must be told without delay, and a full report has to follow within 72 hours covering what happened, when, why, what's being done about it, and confirmation that affected individuals were notified. Unlike GDPR, there's no minimum severity threshold here. A breach affecting ten people triggers the same obligation as one affecting ten million. And CERT-In's existing six hour reporting window under its 2022 Directions still applies separately, which means a serious incident can trigger two overlapping regulatory clocks running side by side.

Put all of this together and a pattern emerges. The law assumes an organisation already knows what it's protecting, has actually protected it, kept usable records the whole way through, and can explain clearly what happened the moment something breaks. That coordination job belongs to Governance, Risk and Compliance, or GRC for short. GRC decides who's accountable, which risks actually matter, which controls address them, and how anyone checks whether compliance is real rather than assumed. Skip that structure and security work tends to splinter into a pile of disconnected tasks nobody truly owns.

GRC gives a legal duty somewhere to live. Forensic readiness is what lets an organisation prove, months or years later, that the duty was actually being met.

The Role of Governance, Risk and Compliance

On paper, most cybersecurity programmes look fine. There's an incident response plan somewhere, access control rules exist, logging is "in place," and someone has a title that says they're responsible for security. None of that gets tested until something actually breaks. A phishing compromise, a ransomware infection, a leaked database, a hijacked admin account, whatever the trigger, the questions that follow are always the same, and they're not comfortable ones. What happened, exactly, and when did it start? Which systems, which data, were actually touched? Were the controls the organisation claims to run genuinely functioning at that moment, or just described in a slide deck somewhere? And can anyone produce records solid enough to answer those questions with confidence rather than a shrug?

This is the exact seam where GRC and digital forensics meet. GRC lays out what's expected, who's responsible, and what evidence a control should be generating in the background. Digital forensics is the craft of taking whatever technical traces actually exist and turning them into an account of events that will hold up to scrutiny. Passing an audit was never really the point. Being able to stand in front of a regulator, mid incident, and show that the processes described on paper were real, active, and generating trustworthy evidence, that's the actual bar.

Why Compliance Alone Falls Short

Compliance, in the narrow sense, just means meeting whatever legal, contractual, or internal requirement applies. But a policy sitting in a document repository proves nothing about what actually happens on a Tuesday afternoon when someone requests admin access. A written incident response plan says nothing about whether the team can actually execute it under real pressure, at 2am, with a ransomware note on every screen. A logging policy is close to worthless if the logs it promises were switched off somewhere along the way, or overwritten, or scattered across systems that were never synchronised to the same clock.

NIST's Cybersecurity Framework 2.0 essentially built this concern into its core structure, placing "Govern" alongside Identify, Protect, Detect, Respond, and Recover as one of five equal functions rather than background paperwork sitting off to the side. India's own regulatory posture pushes in the same direction. CERT-In's 2022 Directions require certain incidents to be reported within six hours of discovery, and its guidance for government entities leans heavily on documented incident handling and disciplined evidence practices. The underlying message from both is identical: figure out, before anything goes wrong, whether the evidence you'll eventually need is actually going to exist when someone asks for it.

Where GRC and Forensics Actually Connect

A good GRC programme spells out what's supposed to happen. Forensic readiness is what lets you later prove what actually did.

Access control is a useful example here. On the GRC side, an organisation might require least privilege access, multi factor authentication, periodic reviews of who holds privileged accounts, and prompt removal of access once someone leaves or changes roles. On the forensic side, none of that means anything without the underlying records that let investigators actually test it, authentication logs, MFA usage history, privilege change records, and account activity trails. The table below lines up a few common GRC controls against the specific evidence needed to show they were genuinely operating.

‍

A Practical Scenario: After a Ransomware Incident

Picture a mid-sized company waking up to find half its file servers encrypted. There's an incident response plan somewhere in the shared drive, technically, but nobody's actually run through it in over a year. The security team isolates the obviously compromised endpoint and starts escalating. Now the forensic side of the house has to reconstruct what happened, working backward through endpoint telemetry, authentication logs, firewall events, email traffic, and file activity, hunting for the original point of entry, how the attacker escalated privileges, how they moved sideways through the network, what data they actually touched, and finally how the ransomware got deployed.

This is where the quality of everything collected beforehand suddenly matters a great deal. If server clocks were never properly synchronised, the timeline investigators build might not line up cleanly enough to trust. If logs only ever lived locally on individual machines rather than being pulled centrally, some of them are probably gone by now. If nobody ever bothered logging administrator actions, there are going to be real, unexplained gaps in the story. And if whatever evidence does exist wasn't collected the right way, its integrity can be challenged later, sometimes fatally, in a legal or regulatory proceeding. CERT-In actually ran a programme on exactly this in July 2026, "Inside the Breach," covering system artefacts, investigative technique, and chain of custody requirements, precisely because this is where real investigations tend to succeed or quietly fall apart.

Building a Forensic Ready GRC Programme

For an organisation starting more or less from scratch, forensic readiness doesn't need to be bolted on as some separate initiative. It can be built straight into the GRC programme that already exists. Start by identifying the systems, applications, cloud services, and privileged accounts that actually matter. Map the real risks and regulatory requirements onto the controls meant to address them. Then get specific about what evidence each control should be generating, and how that evidence gets protected and kept over time. Time synchronisation, centralised logging, tightly controlled access to security records, and clear ownership of preservation, escalation, and investigation all need to exist well before an incident, not be improvised during one. And none of it means much until it's actually been tested, through tabletop exercises and simulated incidents rather than assumed to work because it's written down somewhere. NIST SP 800-61 Revision 3 frames incident response as one continuous loop of preparation, detection, response, recovery, and improvement, rather than a series of separate boxes to check.

There's one question worth asking of every important control an organisation runs: could you actually prove this was working at the moment an incident happened? If the honest answer is no, what you have is a compliance process on paper, and a forensic readiness gap sitting quietly underneath it.

Conclusion

Cyber readiness was never really about how many policies sit in a binder or how many boxes get ticked in an audit. It shows up, or doesn't, in the hours right after something breaks, when an organisation has to move fast, preserve evidence that can actually stand up to scrutiny, explain clearly what happened, and prove that governance and technical controls were genuinely working together rather than just coexisting on paper. GRC sets the direction, the accountability, the risk priorities, and the compliance expectations. Digital forensics does the work of preserving and interpreting the technical evidence once something actually happens. Forensic readiness sits in between the two, making sure they're actually talking to each other long before an incident forces the conversation. The practical task for most organisations comes down to something simple to say, if not always simple to build: design controls that hold up under real incident response, not just an auditor's checklist. The strongest compliance posture was never the one with the thickest binder. It's the one that can back every document up with evidence, on the day it actually matters.

References

1. Digital Personal Data Protection Act, 2023, Sections 8(4), 8(5), 8(6). https://www.meity.gov.in/writereaddata/files/Digital%20Personal%20Data%20Protection%20Act%202023.pdf
2. Digital Personal Data Protection Rules, 2025, Rules 6 and 7, notified 13 November 2025. https://www.meity.gov.in
3. National Institute of Standards and Technology, The NIST Cybersecurity Framework (CSF) 2.0, CSWP 29, 2024. https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final
4. Indian Computer Emergency Response Team (CERT-In), Directions under Section 70B of the Information Technology Act, 2000, dated 28 April 2022. https://www.cert-in.org.in/Directions70B.jsp
5. Indian Computer Emergency Response Team (CERT-In), Guidelines on Information Security Practices for Government Entities. https://www.cert-in.org.in/Downloader?fileName=CIPS-2026-0014.pdf&pageid=5&type=2
6. National Institute of Standards and Technology, SP 800-86: Guide to Integrating Forensic Techniques into Incident Response, 2006. https://csrc.nist.gov/pubs/sp/800/86/final
7. International Organization for Standardization, ISO/IEC 27037:2012, Guidelines for identification, collection, acquisition and preservation of digital evidence. CERT-In, "Inside the Breach: Advanced Cyber Forensics & Incident Investigation," 31 July 2026. https://www.cert-in.org.in/s2cMainServlet?pageid=PRSTNVIEW03&reCode=CIWS-2026-3569
8. National Institute of Standards and Technology, SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management, 2025. https://csrc.nist.gov/pubs/sp/800/61/r3/final
9. Matters.ai, "DPDP Breach Notification: 72-Hour Rule & ₹200 Cr Penalty." https://www.matters.ai/article/dpdp-breach-notification MediaNama, "Data Breach Reporting Timeline of DPDP Rules 2025 Explained." https://www.medianama.com/2025/11/223-data-breach-reporting-timeline-of-dpdp-rules-2025-explained/

‍