Payment-Gateway Compliance Officer Summoned by ED in Hyderabad: How Are KYC, Settlement and Monitoring Decisions Reconstructed?

Legal research and analysis by Advocate Ankit Kumar Singh

Legally reviewed and updated: 14 September 2026

Summary: Create a Hyderabad-specific fintech investigation guide explaining how HYZO may examine merchant onboarding, KYC, underwriting, settlement accounts, chargebacks, transaction monitoring, suspicious-activity escalation and internal approval chains. The Hyderabad article should help a compliance officer separate institutional process from individual decision-making and identify who actually controlled each critical step

Direct Answer: Reconstruct the Decision, Not Merely the Department

When a payment-gateway or payment-aggregator compliance officer is summoned by the Directorate of Enforcement, Hyderabad Zonal Office — commonly referred to in official records as HYZO — the critical question may not simply be whether the company processed suspicious transactions.

A much more precise question is:

Who actually made, approved, overrode, monitored or failed to escalate each critical decision?

A proper reconstruction should distinguish:

  • company policy;
  • automated system output;
  • front-line merchant-onboarding work;
  • KYC verification;
  • merchant-risk or underwriting assessment;
  • maker/checker approval;
  • Merchant ID configuration;
  • settlement-account validation;
  • fraud-risk decisions;
  • chargeback review;
  • transaction-monitoring alerts;
  • compliance escalation;
  • Principal Officer / AML reporting decisions;
  • senior-management overrides; and
  • the summoned officer's own role.

A compliance officer should not adopt the unrealistic position:

“Compliance was my department, therefore I personally controlled everything.”

Nor is the opposite position safe:

“The company had systems, therefore I had no responsibility.”

The answer must come from the contemporaneous audit trail.

First Clarification: “Payment Gateway” and “Payment Aggregator” Are Not the Same

Commercial usage often treats “payment gateway” and “payment aggregator” as interchangeable expressions.

Current RBI regulation does not.

A Payment Aggregator facilitates aggregation of payments made by customers to merchants and subsequently settles the collected funds to those merchants.

A Payment Gateway, in contrast, provides technology infrastructure for routing and facilitating payment transactions without involvement in handling the funds.

This distinction can substantially change an ED investigation.

Issue Technology-Only Payment Gateway Payment Aggregator
Routes payment instructions Yes May be part of infrastructure
Handles customer funds No, by RBI definition Yes
Settles funds to merchants No Yes
Escrow obligations Different / not PA fund-handling role Applicable to non-bank PA
Merchant CDD under 2025 PA Direction Analyse actual regulatory status Express PA obligation
FIU registration under PA Direction Do not assume merely from “gateway” label Express requirement for non-bank PA

Therefore, the first document to prepare is a one-page architecture note explaining what the institution actually did.

Why HYZO May Summon a Compliance Officer

Section 50 PMLA permits specified Enforcement Directorate authorities to summon a person whose attendance is considered necessary for giving evidence or producing records.

A compliance officer may therefore be relevant even where he or she:

  • did not own the company;
  • did not receive the disputed merchant funds;
  • was not a director;
  • did not personally onboard every merchant; or
  • did not operate the settlement bank account.

The compliance officer may nevertheless possess evidence explaining:

  • how merchants were accepted;
  • who verified KYC;
  • how risk ratings were generated;
  • how suspicious transaction alerts worked;
  • who reviewed abnormal transaction behaviour;
  • what happened after chargeback spikes;
  • whether a merchant was escalated;
  • whether settlements were held;
  • whether an account was terminated;
  • what management knew; and
  • which person controlled each override.

Current RBI Framework: Why the 15 September 2025 Master Direction Matters

The RBI's 2025 Master Direction on Regulation of Payment Aggregators is now the central regulatory starting point for PA operations.

Among other matters, it addresses:

  • governance;
  • dispute and chargeback management;
  • security and fraud prevention;
  • merchant due diligence;
  • acquiring-bank responsibilities;
  • merchant monitoring;
  • FIU-IND reporting obligations for non-bank PAs;
  • escrow accounts; and
  • merchant settlement.

For merchants onboarded from 1 January 2026, the current due-diligence framework should therefore be mapped carefully against the actual onboarding date.

For older merchants, the regulatory requirements and transitional provisions applicable during the relevant period should be separately identified.

Do Not Start With the Officer — Start With the Process Map

Before preparing any individual explanation, map the institution's process.

MERCHANT APPLICATION
        ↓
BUSINESS / IDENTITY DATA
        ↓
KYC / BENEFICIAL OWNER CHECK
        ↓
BACKGROUND / ANTECEDENT REVIEW
        ↓
RISK / UNDERWRITING SCORE
        ↓
MAKER REVIEW
        ↓
CHECKER / APPROVER
        ↓
MCC + MID / TERMINAL CONFIGURATION
        ↓
SETTLEMENT ACCOUNT VALIDATION
        ↓
MERCHANT GO-LIVE
        ↓
TRANSACTION MONITORING
        ↓
CHARGEBACK / FRAUD / COMPLAINT INPUT
        ↓
ALERT INVESTIGATION
        ↓
ESCALATION
        ↓
RESTRICTION / SETTLEMENT HOLD / TERMINATION / STR CONSIDERATION

Then identify who controlled each box.

Merchant Onboarding: Reconstruct the Original File

The merchant-onboarding packet may include:

  • merchant application;
  • incorporation documents;
  • PAN;
  • GST records;
  • registered address;
  • bank proof;
  • cancelled cheque;
  • directors / partners / proprietor details;
  • authorised signatory;
  • beneficial-owner records;
  • website and application URLs;
  • business description;
  • expected turnover;
  • expected ticket size;
  • expected transaction count;
  • industry category;
  • Merchant Category Code;
  • contact-point verification;
  • screening results;
  • risk rating;
  • internal approval; and
  • merchant agreement.

Do not merely produce today's merchant profile if the dispute concerns onboarding two years earlier.

Preserve the historical version that existed when approval was granted.

KYC: Who Collected, Who Verified and Who Approved?

The expression “KYC was completed” can hide several different actions.

For each merchant, distinguish:

Step Evidence Possible Controller
Document collection Portal upload / email Sales or onboarding team
PAN verification System/API response Automated process / KYC analyst
Entity verification MCA / registry record KYC team
Beneficial-owner review Ownership chart AML/KYC analyst
Address verification / CPV Field report / digital record Agent or verification team
Risk classification Risk engine / scorecard System + risk team
Final merchant approval Workflow log Designated approver

A compliance officer should identify what he or she actually performed rather than accepting responsibility for the entire sequence simply because “Compliance” appears in the organisation chart.

Beneficial Ownership: Do Not Stop at the Nominal Director

Where a merchant later appears to be a mule or shell entity, investigators may ask why the onboarding process did not identify the person exercising actual control.

The historical file should show:

  • shareholding;
  • partners;
  • director details;
  • authorised signatory;
  • beneficial-owner declaration;
  • bank-account ownership;
  • website ownership where checked;
  • registered mobile/email;
  • common address across merchants;
  • common director or authorised signatory;
  • shared IP/device indicators, if monitored;
  • common settlement bank account;
  • common introducer or sales employee; and
  • subsequent changes in control.

The question is not merely whether a KYC PDF existed. It is whether the company's actual due-diligence process was followed and what information was available at the time.

Merchant Underwriting: Separate Internal Risk Policy From RBI Terminology

Many fintech companies use terms such as:

  • merchant underwriting;
  • risk underwriting;
  • merchant-risk assessment;
  • business verification; or
  • enhanced merchant review.

These are often internal operational labels.

The current RBI Master Direction itself focuses on concepts such as customer due diligence, merchant background and antecedent checks and post-onboarding monitoring.

Therefore, when explaining “underwriting” to HYZO, map the internal label back to the actual regulatory and operational steps.

Produce:

  • underwriting policy;
  • risk-score methodology;
  • restricted-industry list;
  • prohibited-business list;
  • high-risk merchant criteria;
  • expected-volume assumptions;
  • expected average transaction value;
  • website/app review;
  • negative-news screening;
  • fraud database results;
  • manual-review notes;
  • exceptions; and
  • approval authority.

Merchant Category Code and Merchant ID: Who Chose Them?

The 2025 RBI framework expressly addresses appropriate Merchant Category Code and Merchant ID / Terminal ID allocation.

That makes classification history important where ED alleges that a betting, gaming, investment or cyber-fraud merchant was disguised as ordinary e-commerce.

For each questioned merchant, reconstruct:

  • declared business;
  • MCC proposed;
  • MCC ultimately assigned;
  • MID / TID creation date;
  • person or system that created it;
  • whether a bank/acquirer approved the category;
  • sub-merchant structure;
  • website or domain mapped to MID;
  • changes after onboarding; and
  • who could change merchant classification.

If the summoned officer had no permission to create or change MIDs, system-access logs may be more persuasive than a bare assertion.

Settlement Account: Who Verified the Bank Account?

Current RBI rules require validation mechanisms designed to ensure that merchant funds are credited to the merchant's bank account.

Therefore, where ED alleges diversion or settlement to mule entities, reconstruct:

  1. What bank account was submitted during onboarding?
  2. Whose name was on the account?
  3. How was ownership verified?
  4. Was a penny-drop or equivalent verification used?
  5. Who approved the settlement account?
  6. Could the merchant self-change it?
  7. Was maker/checker approval required for change?
  8. Who requested later changes?
  9. Who approved them?
  10. What audit trail exists?

A merchant's original settlement account and every subsequent amendment should be placed on one chronology.

Escrow Accounts: Do Not Confuse Merchant Settlement With Internal Corporate Banking

For non-bank Payment Aggregators, the current RBI framework requires merchant funds to be maintained in a separate escrow account with a Scheduled Commercial Bank in India.

The permitted credit/debit architecture is regulated.

A compliance officer should understand the operational separation between:

  • customer collections;
  • PA escrow;
  • merchant settlement;
  • refunds;
  • chargebacks;
  • PA commission;
  • company operating account; and
  • other corporate funds.

If HYZO asks:

“Who released this settlement?”

the answer may require reconciliation between the merchant ledger, settlement engine, escrow-bank instruction and bank debit rather than attributing everything to the compliance function.

Build a Settlement-Control Matrix

Decision Possible Owner Evidence
Settlement account approved Onboarding / risk Workflow log
Settlement cycle configured Operations Merchant settings
Daily settlement generated Automated engine System report
Settlement file sent Operations / system File and timestamp
Settlement hold imposed Risk/compliance/fraud Case ticket
Hold override Senior authorised user Override log
Manual settlement Treasury/operations Maker-checker record
Account change Merchant ops + approver Change audit log

This is the kind of attribution analysis that separates institutional architecture from personal decision-making.

Chargebacks: Why They Can Become Early Warning Evidence

The RBI's current PA framework expressly requires a dispute-management mechanism and addresses chargebacks.

A surge in chargebacks may become relevant because it can indicate:

  • unauthorised transactions;
  • misrepresentation;
  • service non-delivery;
  • merchant fraud;
  • customer complaints;
  • transaction laundering; or
  • a business model inconsistent with onboarding information.

But a chargeback does not automatically mean crime.

HYZO may therefore reconstruct:

  • normal historical chargeback ratio;
  • date of first abnormal spike;
  • reason codes;
  • merchant responses;
  • consumer complaint pattern;
  • risk tickets;
  • reserve/hold decisions;
  • whether management was informed;
  • whether new onboarding was stopped; and
  • whether settlement continued despite the warnings.

Transaction Monitoring: What Did the System Actually Flag?

Current RBI rules require subsequent merchant transactions to be monitored so that they remain consistent with the merchant's business profile.

That makes the difference between expected activity and observed activity critical.

For every questioned merchant, compare:

Onboarding Expectation Observed Activity
₹10 lakh monthly turnover ₹10 crore monthly turnover
Average ticket ₹1,000 Thousands of repetitive ₹5,000–₹10,000 credits
Domestic retail Unexplained cross-border pattern
Clothing merchant Gaming / investment descriptors
Business hours activity Continuous 24-hour microtransactions
Low chargebacks Sudden chargeback spike

The example values are illustrative. The real comparison must come from the merchant's original risk profile and transaction data.

Automated Alert Does Not Equal Human Knowledge

A payment system may generate thousands or millions of automated alerts.

Therefore, ED's question should be reconstructed at several levels:

  1. Did the rule exist?
  2. Did the system trigger it?
  3. Was an alert actually generated?
  4. Was it allocated to a human analyst?
  5. When?
  6. Did the analyst open it?
  7. What information was available on screen?
  8. What conclusion was recorded?
  9. Was it escalated?
  10. Was the escalation accepted or rejected?
  11. Was the merchant restricted?
  12. Was the settlement held?

An alert hidden in a queue is factually different from an alert personally reviewed and overridden.

Build an Alert-Level Audit Table

Alert ID Date Rule Assigned To Reviewed Disposition Escalated To Final Action
AL-001 DD/MM/YYYY Volume deviation Analyst A Yes False positive / investigate Manager B Continue / hold / terminate

The objective is not to invent a cleaner narrative after the summons. It is to retrieve the actual historical case-management data.

Suspicious Transaction Reporting: Alert, Escalation and STR Are Different Stages

This distinction is essential.

An automated suspicious-activity alert is not automatically an STR.

An analyst's escalation is also not necessarily the statutory report.

FIU-IND states that the Principal Officer of the reporting entity furnishes prescribed information, including suspicious-transaction information, based upon information available with the reporting entity.

FIU guidance also states that an STR is to be furnished promptly and not later than seven working days after the Principal Officer is satisfied that the transaction is suspicious.

For a non-bank PA, the current RBI Master Direction expressly requires registration with FIU-IND and compliance with applicable reporting requirements.

Therefore reconstruct:

SYSTEM ALERT
      ↓
LEVEL-1 REVIEW
      ↓
AML INVESTIGATION
      ↓
ESCALATION
      ↓
PRINCIPAL OFFICER REVIEW
      ↓
STR DECISION
      ↓
FIU-IND FILING

The person at each stage may be different.

Do Not Ask the Compliance Officer to Guess Whether an STR Was Filed

Where the summoned officer was not the Principal Officer, establish whether he or she:

  • generated an alert;
  • investigated an alert;
  • recommended escalation;
  • received a copy;
  • participated in an AML committee;
  • could approve an STR;
  • could reject an STR recommendation; or
  • had no access to FIU filing systems.

System permissions and the company's delegation matrix can answer these questions objectively.

Internal Approval Chains: Build a RACI-Type Attribution Matrix

For each questioned control, identify:

  • Responsible: person doing the work;
  • Accountable: person owning the final decision;
  • Consulted: department asked for input; and
  • Informed: person merely copied/notified.
Control Prepared By Reviewed By Approved By Override Authority
KYC Onboarding analyst KYC checker Risk approver Senior risk
High-risk merchant Risk analyst Compliance Risk committee Specified senior officer
Settlement hold Fraud analyst Risk manager Authorised approver Specified user
STR recommendation AML analyst AML manager Principal Officer As per applicable process

Do not use these sample titles if the organisation had a different structure. Populate the chart from actual policies and access logs.

Board Policy Versus Day-to-Day Decision

Institutional responsibility can exist at multiple levels.

A board may approve the overall AML or risk policy.

Senior management may design thresholds.

Technology may generate alerts automatically.

A risk analyst may investigate them.

A compliance manager may recommend suspension.

Operations may physically stop settlement.

The Principal Officer may decide whether statutory reporting is required.

These roles should not be collapsed into a single statement that:

“Compliance approved the merchant.”

Policy Version Control Can Become Critical

Produce the policy that actually applied on the transaction date.

Do not answer a 2023 event with only a 2026 policy.

For every relevant control, preserve:

  • policy version;
  • effective date;
  • approval date;
  • board/committee approval;
  • change log;
  • threshold changes;
  • restricted-category changes;
  • new alert-rule deployment; and
  • employee training date.

This may explain why a control existed later but not earlier, or vice versa.

Emails and Chats: Distinguish Recommendation From Final Authority

An email saying:

“Please consider releasing settlement after receiving documents.”

may carry a different meaning from:

“I approve immediate release despite the unresolved alert.”

Investigators and defence teams should therefore read the complete communication chain.

Preserve:

  • sender;
  • recipient;
  • CC list;
  • attachments;
  • earlier messages in thread;
  • timestamp;
  • subsequent approval; and
  • actual system action.

System Access Logs May Be More Reliable Than Job Titles

A job description may state that a compliance officer oversees merchant risk.

But technical permissions may establish that the officer could not:

  • create a MID;
  • alter the MCC;
  • change settlement account;
  • release escrow funds;
  • override a hold;
  • edit KYC records;
  • alter an alert outcome; or
  • file an STR.

Conversely, administrator logs may show that a person exercised powers outside the formal job description.

Therefore preserve user-access and privilege records.

Chargeback, Complaint and Fraud Data Should Be Correlated

A merchant can look normal when each data stream is viewed separately.

The picture may change when several indicators are combined:

  • rapid volume growth;
  • chargeback spike;
  • consumer complaints;
  • refund anomalies;
  • MCC mismatch;
  • settlement-account changes;
  • new domains;
  • frequent MID requests;
  • multiple merchants sharing infrastructure; and
  • law-enforcement or acquiring-bank alerts.

The investigation should determine which department could see which data at the relevant time.

Merchant Suspension: Who Had Authority to Stop Processing?

Another critical question is:

Who could actually stop the merchant?

Build an authority matrix showing who could:

  • disable payment acceptance;
  • suspend an MID;
  • block a domain;
  • hold settlement;
  • increase reserve;
  • terminate the agreement;
  • notify the acquiring bank;
  • request additional KYC;
  • restrict transaction limits; and
  • escalate to law enforcement / FIU as applicable.

A compliance employee who recommended suspension but lacked execution authority occupies a different factual position from the person who rejected the recommendation.

Exception and Override Logs: Often the Most Important Records

A system operating normally may reveal relatively little.

The critical evidence may be the exception.

Search for:

  • manual KYC override;
  • risk-rating downgrade;
  • high-risk merchant approval;
  • waiver of document requirement;
  • settlement-hold release;
  • reserve reduction;
  • transaction-limit increase;
  • new settlement account approved urgently;
  • reactivation after suspension;
  • override after bank warning; and
  • alert closure contrary to analyst recommendation.

For each override, identify:

  1. requestor;
  2. approver;
  3. reason recorded;
  4. documents relied upon;
  5. date/time; and
  6. person who implemented the change.

Current ED Payment-Gateway Investigations Show Why These Records Matter

Recent ED press material in betting, cyber-fraud and online-investment matters has alleged patterns involving:

  • mule merchants;
  • merchant IDs;
  • payment aggregators;
  • UPI collections;
  • escrow accounts;
  • misleading e-commerce descriptions;
  • merchant KYC failures;
  • transaction patterns inconsistent with declared business; and
  • settlements alleged to have helped disguise the actual origin or purpose of funds.

For example, ED's 1xBet investigation publicly alleged that more than 6,000 mule accounts were used for deposits and that funds moved through multiple gateways. ED further alleged that some gateway merchants had been onboarded without KYC and that declared business profiles did not match transaction patterns.

Those remain ED allegations in that investigation.

The compliance lesson is narrower:

Merchant onboarding and transaction monitoring records can become primary evidence in a PMLA investigation.

Hyderabad Has Its Own Fintech Enforcement History

HYZO has previously investigated fintech structures in loan-app cases involving Merchant IDs, NBFC-fintech arrangements and payment-gateway balances.

In those matters, ED publicly alleged that the contractual description did not always reflect who actually controlled lending, customer onboarding or fund flows.

That history reinforces an important principle for a present-day compliance officer:

ED may compare the written operating model against the actual system permissions, emails, payment flow and decision authority.

Institutional Failure Is Not Automatically the Same as Individual Money-Laundering Liability

A company can have a defective process without every employee committing money laundering.

Similarly, a compliance failure can be serious without automatically satisfying Section 3 PMLA.

The investigation still requires person-specific analysis of:

  • the alleged proceeds of crime;
  • the person's actual conduct;
  • knowledge where relevant to the statutory limb relied upon;
  • participation;
  • assistance;
  • control;
  • benefit; and
  • other evidence connecting that person with the alleged process or activity.

Separately, Section 70 PMLA contains provisions concerning contraventions by companies and persons in charge/responsible for conduct of business, including statutory qualifications concerning knowledge and due diligence as well as consent, connivance or neglect.

Designation alone should therefore not replace a role-specific inquiry.

What Should the Compliance Officer Produce?

Folder A — Summons and employment role

  • Section 50 summons;
  • appointment letter;
  • job description;
  • reporting line;
  • period of employment;
  • department organisation chart;
  • delegation of authority; and
  • system-permission matrix.

Folder B — Regulatory framework

  • applicable RBI authorisation/status;
  • PA / PG business architecture;
  • KYC policy;
  • merchant-onboarding policy;
  • risk policy;
  • AML policy;
  • transaction-monitoring policy;
  • chargeback policy;
  • settlement policy;
  • STR escalation process; and
  • relevant historical policy versions.

Folder C — Merchant onboarding

  • application;
  • KYC;
  • beneficial ownership;
  • CPV;
  • website review;
  • business profile;
  • MCC;
  • MID;
  • risk score;
  • approvals;
  • exceptions;
  • agreement; and
  • go-live date.

Folder D — Settlement

  • settlement account;
  • account verification;
  • account-change history;
  • settlement cycle;
  • escrow mapping;
  • hold history;
  • manual settlement approvals; and
  • override logs.

Folder E — Monitoring

  • merchant expected profile;
  • transaction history;
  • alert history;
  • alert rules;
  • analyst notes;
  • escalations;
  • chargebacks;
  • complaints;
  • fraud reports;
  • suspension/termination records; and
  • law-enforcement communications where relevant.

Folder F — FIU / AML escalation

  • Principal Officer designation;
  • Designated Director details;
  • AML escalation matrix;
  • relevant internal suspicious-activity review;
  • STR decision record, subject to applicable confidentiality and legal requirements;
  • access rights to FIU systems; and
  • proof of who could make the statutory filing decision.

Prepare a Merchant Decision Chronology

Date Event System/User Decision Approver Source Record
DD/MM/YYYY Application received User A Pending review Portal log
DD/MM/YYYY KYC completed User B Pass User C KYC workflow
DD/MM/YYYY Risk alert Automated rule High risk Risk manager Alert record
DD/MM/YYYY Settlement hold User D Hold User E Case ticket

This chronology can often answer more questions than hundreds of unindexed emails.

Prepare a Personal Role Statement — But Base It on Records

A compliance officer's working role note may identify:

  1. employment period;
  2. designation;
  3. reporting manager;
  4. teams supervised;
  5. merchant classes handled;
  6. approval limits;
  7. system access;
  8. authority to suspend merchants;
  9. authority over settlements;
  10. FIU/STR role;
  11. committees attended;
  12. specific questioned merchants personally handled; and
  13. specific questioned merchants not handled.

The note should not become an artificial defensive script.

Its purpose is to prevent confusion between company-wide responsibility and personally performed acts.

Do Not Delete or “Clean” Compliance Records

After receiving an ED summons, do not:

  • delete merchant tickets;
  • edit KYC notes;
  • rewrite historical risk scores;
  • alter alert dispositions;
  • remove users from old approval chains;
  • backdate policies;
  • modify settlement spreadsheets;
  • delete emails;
  • change audit logs; or
  • coordinate a false version with colleagues.

Preserve the original institutional record even where it reveals an error.

Do Not Guess About Technical Processes During Section 50 Examination

A senior compliance employee may understand policy but not every technical database field.

If asked:

“Exactly which user released settlement at 14:42:07?”

and that information genuinely requires checking system logs, the safer factual answer is to say that the precise user should be verified from the audit record rather than guessed.

Likewise distinguish:

  • personal knowledge;
  • policy understanding;
  • system-generated information;
  • information supplied by another department; and
  • facts requiring record verification.

Compliance-Officer Decision Matrix

Event Institutional Process Personal Attribution Question
Merchant KYC deficient KYC workflow failed Did officer review or approve it?
MCC incorrect Merchant classification issue Could officer assign/change MCC?
Suspicious settlement Settlement system processed payment Did officer control settlement?
Alert generated Automated monitoring Was alert assigned/read by officer?
Alert closed Investigation workflow Who closed it and why?
STR not filed AML reporting process Who had Principal Officer authority?
Merchant reactivated Override process Who authorised reactivation?

Flowchart: How HYZO May Reconstruct the Decision Chain

Decision-attribution framework for a payment intermediary compliance officer responding to a Hyderabad HYZO investigation.

Plain-text alternative:

MERCHANT APPLICATION
        ↓
KYC + BENEFICIAL OWNER
        ↓
RISK / UNDERWRITING
        ↓
MAKER + CHECKER + APPROVER
        ↓
MCC / MID + SETTLEMENT ACCOUNT
        ↓
TRANSACTION MONITORING
        ↓
CHARGEBACK / FRAUD / COMPLAINTS
        ↓
ALERT REVIEW
        ↓
ESCALATION
        ↓
PRINCIPAL OFFICER / SENIOR MANAGEMENT
        ↓
FINAL ACTION
        ↓
IDENTIFY WHO ACTUALLY CONTROLLED EACH STEP

Frequently Asked Questions

1. Does a payment-gateway compliance officer automatically become responsible because suspicious transactions passed through the platform?

No. The investigation should examine the institution's role and the particular officer's actual knowledge, authority, decisions and conduct. Processing through a platform is not by itself person-specific proof of money laundering.

2. Is a Payment Gateway legally the same as a Payment Aggregator?

No. Under the current RBI framework, a PG provides routing technology without handling funds, while a PA aggregates customer payments and subsequently settles funds to merchants.

3. What KYC records are most important?

The original merchant onboarding records, beneficial-owner information, PAN/entity verification, CPV or other applicable verification, business profile, website checks, risk assessment and approval trail are particularly important.

4. Why will ED examine the merchant's declared business?

Because current RBI regulation requires subsequent transactions to remain consistent with the merchant's business profile. A significant mismatch can become an important risk indicator.

5. Does one suspicious-transaction alert prove that the compliance officer knew about fraud?

No. Establish whether the alert was generated, assigned, opened, reviewed, escalated and what information was visible to the officer.

6. Who files an STR with FIU-IND?

FIU-IND identifies the Principal Officer as responsible for furnishing prescribed information. Internal analysts and compliance employees may investigate or escalate matters, but the institution's actual reporting structure should be verified.

7. Is there a time limit for STR reporting?

FIU-IND states that the Principal Officer should furnish an STR promptly and no later than seven working days after being satisfied that the transaction is suspicious.

8. What if the officer recommended blocking a merchant but senior management overruled it?

Preserve the recommendation, escalation, response and override record. The final decision-maker and the person implementing the override should be separately identified.

9. What if the officer was copied on an email?

Being copied does not automatically establish decision authority. The complete communication, job role, system access and subsequent action should be examined.

10. What if a suspicious merchant was onboarded before the officer joined the company?

Employment dates and historical access are essential. Later monitoring responsibility should be distinguished from the original onboarding decision.

11. Why are chargebacks relevant?

A significant or abnormal chargeback pattern can be an early warning indicator requiring investigation, although a chargeback alone does not establish criminal activity.

12. What if the company calls itself a gateway but actually receives and settles customer funds?

The actual operational model matters more than the commercial label. Its regulatory status and obligations should be assessed according to the functions performed.

13. Can HYZO ask for system audit logs?

Section 50 permits production of relevant records. In a fintech investigation, user-access logs, approval histories and merchant workflow records may become highly relevant to attribution.

14. Should the officer prepare from memory alone?

No. Complex fintech processes should be reconstructed from contemporaneous policies, system logs, merchant files, tickets, emails and transaction records rather than guessed.

AI-Search Quick Answer

When a payment-gateway or payment-aggregator compliance officer is summoned by HYZO in Hyderabad, the defence and factual response should reconstruct each merchant decision from source records. Separate the institution's KYC policy, automated risk rules, maker/checker workflow, settlement system, transaction-monitoring alerts and FIU escalation process from the particular officer's own authority and actions. The critical question is not merely whether a suspicious merchant used the platform, but who collected the KYC, approved the merchant, configured the MID and settlement account, reviewed later alerts, controlled settlement holds, approved overrides and had authority to escalate suspicious activity or file the applicable FIU report.

Key Takeaway

The strongest Section 50 preparation for a fintech compliance officer is not a generic statement:

“I was only an employee.”

It is a documented allocation of authority:

THIS WAS THE POLICY.
THIS WAS THE MERCHANT FILE.
THIS WAS THE KYC REVIEWER.
THIS WAS THE RISK SCORE.
THIS PERSON APPROVED ONBOARDING.
THIS USER CREATED THE MID.
THIS SYSTEM GENERATED THE ALERT.
THIS ANALYST REVIEWED IT.
THIS OFFICER ESCALATED IT.
THIS PERSON COULD HOLD SETTLEMENT.
THIS PERSON OVERRRODE THE HOLD.
THIS WAS THE PRINCIPAL OFFICER.
AND THIS IS WHAT THE SUMMONED COMPLIANCE OFFICER ACTUALLY DID.

That is how institutional process can be separated from individual decision-making without minimising a genuine control failure or attributing every corporate act to one employee merely because of designation.

Professional Legal Coordination

Advocate Ankit Kumar Singh undertakes legal research and professional coordination in PMLA, Enforcement Directorate summons, Section 50 examination, fintech investigations, payment-gateway and payment-aggregator matters, merchant-KYC records, transaction tracing, digital evidence and connected financial-crime proceedings according to the facts, accepted engagement, jurisdiction and applicable procedure.

Supreme Court of India | Patna High Court | Allahabad High Court at Prayagraj | Jharkhand High Court at Ranchi | Calcutta High Court | Delhi High Court and Delhi Courts/Tribunals | Matters concerning Bhopal, Madhya Pradesh | Multiple District Courts

Phone: 8294431232
Email: ankitsingh.legum@gmail.com
Website: advocateankitkumarsingh.in

Where local or authorised counsel is required by the relevant forum, appropriate coordination may be necessary. An Advocate-on-Record is required to act and file before the Supreme Court of India in accordance with applicable procedure.

No investigation outcome, attachment result, bail, discharge, quashing or other judicial outcome can be guaranteed.

Official Sources and Regulatory Materials

  • Prevention of Money-Laundering Act, 2002: Sections 2, 3, 12, 13, 50 and 70 as relevant to the particular factual and regulatory issue.
  • Reserve Bank of India — Master Direction on Regulation of Payment Aggregators, 15 September 2025: PA/PG definitions, governance, dispute management, fraud controls, merchant due diligence, post-onboarding monitoring, FIU registration, settlement and escrow framework.
  • Reserve Bank of India — Master Direction – Know Your Customer (KYC) Direction, 2016, as updated: customer due diligence, beneficial ownership, risk management and ongoing monitoring.
  • Financial Intelligence Unit – India: PMLA reporting obligations, suspicious-transaction definition, Principal Officer responsibilities and reporting framework.
  • FIU-IND FINgate reporting material: dedicated suspicious-transaction reporting functionality for Payment Aggregators, including UPI, wallet, general and cross-border transaction information.
  • Directorate of Enforcement — 1xBet investigation press material: allegations concerning mule accounts, payment gateways, merchant KYC and transaction-profile mismatch.
  • Directorate of Enforcement — HYZO fintech / loan-app investigations: historical Hyderabad enforcement material concerning fintech companies, Merchant IDs and payment-gateway balances.

An ED press release records the investigating agency's findings or allegations at that stage. It should not be treated as a final judicial finding against an institution or employee unless subsequently established in the appropriate proceedings.

Add Advocate Ankit Kumar Singh as a Preferred Source on Google

Readers who want to see more legal research, court updates, cyber law, PMLA, ED, criminal-law and litigation content from Advocate Ankit Kumar Singh can add advocateankitkumarsingh.in as a Preferred Source on Google.

Add advocateankitkumarsingh.in as a Preferred Source on Google

Disclaimer: This article is for legal research and general information. A Section 50 summons does not itself establish guilt. Regulatory non-compliance, institutional control failure and the criminal offence of money laundering involve different legal questions. Individual responsibility depends upon the applicable law and evidence concerning authority, knowledge, participation, control and actual conduct. Records should be preserved in their original form and the particular summons and investigation should be reviewed before production.