Prompt Engineering for Indian Fintech Developers: 25 Prompts for Payment Flows, KYC, and Fraud Detection

You are a payment systems developer. Parse this UPI webhook payload and extract a normalized transaction object.

Input webhook payload:
[PASTE_WEBHOOK_JSON_HERE]

Output a JSON object with these fields:
- transaction_id (string)
- upi_transaction_id (string — from upi_txn_id or txnId field)
- vpa_payer (string — source VPA)
- vpa_payee (string — destination VPA)
- amount_paise (integer — amount in paise, not rupees)
- status (enum: PENDING | SUCCESS | FAILED | REVERSED)
- failure_reason (string | null — from errorCode or responseCode, humanized)
- timestamp_ist (ISO8601 in IST timezone)
- gateway (enum: RAZORPAY | PHONEPE | PAYTM | NPCI_DIRECT | UNKNOWN)

If any field cannot be determined from the payload, set it to null. Do not invent values.

You are a reconciliation assistant for an Indian payment company.

I will give you two lists:
1. Bank statement entries (from [BANK_NAME] current account statement)
2. Internal ledger entries for the same date range

For each bank statement entry:
- Find the matching ledger entry (match on: amount exact, date ±1 day, UTR number if present)
- Mark as: MATCHED, UNMATCHED_BANK, or UNMATCHED_LEDGER
- For UNMATCHED entries, suggest the most likely cause: duplicate, timing difference, missing entry, or data error

Bank statement:
[PASTE_BANK_STATEMENT_CSV_OR_TEXT]

Ledger entries:
[PASTE_LEDGER_CSV_OR_TEXT]

Output a reconciliation table with columns: Date | Amount | UTR/Ref | Bank Entry | Ledger Entry | Status | Notes

Generate a user-facing status message for a NACH mandate update.

Mandate details:
- Bank: [BANK_NAME]
- Status code: [STATUS_CODE]
  (Possible codes: INITIATED, PENDING_BANK_APPROVAL, APPROVED, REJECTED, REVOKED, PAUSED, EXPIRED)
- Amount: ₹[AMOUNT] per [FREQUENCY]
- Next debit date: [DATE]
- Rejection reason (if REJECTED): [REASON_CODE]

Requirements:
- Write in simple English (not legal/banking jargon)
- If APPROVED: confirm what will happen and when
- If REJECTED: explain what went wrong in plain terms + one clear action the user can take
- If PAUSED: explain why and what happens to their next payment
- Tone: calm and factual, not apologetic or alarming
- Length: 2-3 sentences maximum
- Include helpline number: [HELPLINE_NUMBER] only if action is required

Generate a GST-compliant invoice in structured JSON format.

Order details:
[PASTE_ORDER_JSON]

Seller details:
- Legal name: [BUSINESS_NAME]
- GSTIN: [GSTIN]
- Address: [ADDRESS]
- State code: [STATE_CODE_2_DIGIT]

Buyer details (if B2B):
- Legal name: [BUYER_NAME]
- GSTIN: [BUYER_GSTIN] (null if B2C)
- State code: [BUYER_STATE_CODE]

Requirements:
- Determine transaction type: IGST (inter-state) or CGST+SGST (intra-state)
- Apply correct GST rate per HSN/SAC code: [HSN_SAC_CODE]
- Calculate tax breakup (CGST/SGST at half rate each for intra-state, or full IGST for inter-state)
- Round totals per GST rounding rules (nearest rupee)
- Generate invoice number in format: [PREFIX]/[YEAR]/[SEQUENCE]
- Include reverse charge applicability flag

Output JSON with fields: invoice_number, invoice_date, seller, buyer, line_items[], tax_breakup, total_amount, is_reverse_charge

Evaluate this refund request against our refund policy.

Customer request:
- Order ID: [ORDER_ID]
- Order date: [ORDER_DATE]
- Payment method: [UPI | CARD | NETBANKING | WALLET]
- Refund reason given: [CUSTOMER_REASON]
- Days since delivery/service: [DAYS]

Our refund policy rules:
[PASTE_POLICY_TEXT_OR_RULES]

Evaluate:
1. Is the request within the refund window? (Yes/No + which rule applies)
2. Does the stated reason qualify under policy? (Yes/No + category)
3. What refund method should be used? (Original payment method / Wallet / Bank transfer)
4. What is the expected refund timeline in business days per RBI TAT guidelines?
5. Any flags or exceptions that need human review?

Output as structured JSON. Do not make policy decisions beyond what the rules explicitly state.

Diagnose this payment failure and generate:
1. A user-facing message (simple English, 1-2 sentences)
2. A support agent note (technical root cause + suggested resolution)
3. A retry recommendation (should user retry immediately / after N hours / contact bank / contact us)

Failure details:
- Gateway: [RAZORPAY | PAYTM | PHONEPE | CASHFREE]
- Error code: [ERROR_CODE]
- Error message from gateway: [RAW_ERROR_MESSAGE]
- Payment method: [UPI | DEBIT_CARD | CREDIT_CARD | NETBANKING]
- Bank/issuer: [BANK_NAME]
- Amount: ₹[AMOUNT]
- Attempt timestamp: [TIMESTAMP]

Common error codes to recognize:
- INSUFFICIENT_FUNDS → balance issue
- INVALID_VPA → wrong UPI ID
- UPI_LIMIT_EXCEEDED → daily/transaction limit hit
- BANK_DOWN → issuer unavailable
- DUPLICATE_TRANSACTION → same payment attempted twice within 10 minutes
- USER_DROPPED → customer abandoned payment page

Split this bill among multiple payers using UPI payment links.

Total amount: ₹[TOTAL]
Split type: [EQUAL | CUSTOM | PERCENTAGE]

Payers:
[LIST_OF_NAMES_AND_UPIS_OR_SPLIT_AMOUNTS]

Requirements:
- Round each amount to nearest rupee
- Ensure sum of splits equals exact total (assign any rounding difference to [PAYER_NAME] or the first payer)
- Generate payment link format: upi://pay?pa=[VPA]&am=[AMOUNT]&cu=INR&tn=[NOTE]
- Add transaction note: [BILL_DESCRIPTION] - [PAYER_NAME]'s share
- Flag if any split amount is below ₹1 (UPI minimum)

Output: JSON array with payer name, amount, UPI link, and QR code data string

Extract structured data from this Aadhaar card OCR text.

OCR text:
[PASTE_OCR_OUTPUT]

Extract and return JSON:
- name (string — as printed, preserve transliteration)
- dob (string — convert to YYYY-MM-DD format)
- gender (M | F | T)
- aadhaar_number (string — 12 digits, masked: XXXX-XXXX-[last 4])
- address (object: house, street, locality, district, state, pincode)
- masked_mobile (string | null — if visible)

Rules:
- Do NOT return unmasked Aadhaar number
- If DOB is given as year only (e.g., "1985"), set dob to "1985-01-01" and add flag dob_approximate: true
- If any field is unclear from OCR, set to null — do not guess

Validate this PAN card entry and check name consistency.

PAN number entered: [PAN_NUMBER]
Name on PAN: [NAME_ON_PAN]
Name from other document (Aadhaar/Bank): [NAME_FROM_OTHER_DOC]

Validate:
1. PAN format check: [A-Z]{5}[0-9]{4}[A-Z]{1} — valid or invalid?
2. 4th character check: P=Individual, C=Company, H=HUF, F=Firm, A=AOP, B=BOI, G=Govt, J=AJP, L=Local, E=LLP
3. Name consistency: Does [NAME_ON_PAN] likely refer to the same person as [NAME_FROM_OTHER_DOC]?
   (Account for: name order differences, initials vs full name, minor spelling variations, maiden vs married name)
4. Risk flags: Any patterns suggesting synthetic identity?

Output: JSON with valid (bool), entity_type, name_match_score (0-1), name_match_reason, risk_flags[]

Analyse this bank statement for income signals and financial health indicators.

Statement period: [START_DATE] to [END_DATE]
Bank: [BANK_NAME]
Account type: [SAVINGS | CURRENT | SALARY]

Statement data:
[PASTE_STATEMENT_CSV_OR_TEXT]

Extract:
1. Monthly income estimate (identify salary credits, regular recurring inflows)
2. Income stability score (1-5: 5=consistent monthly salary, 1=irregular/inconsistent)
3. Average monthly balance (ABM)
4. Debt obligations visible (EMI debits, loan repayments — identify by narration patterns)
5. Debt-to-income ratio estimate
6. Flags: Salary account used as business account? Circular transactions? Round-trip transfers?

Important: This is for credit assessment. Do not fabricate or extrapolate. If data is insufficient for any metric, return null with explanation.

Extract structured data from this GST Registration Certificate (GST REG-06).

Document text/OCR:
[PASTE_DOCUMENT_TEXT]

Extract:
- gstin (string — 15 character GSTIN)
- legal_name (string)
- trade_name (string | null)
- registration_date (YYYY-MM-DD)
- taxpayer_type (Regular | Composition | Casual | Non-Resident | Input Service Distributor | SEZ)
- business_type (string)
- principal_address (object: building, street, city, district, state, pincode)
- hsn_sac_codes (array of strings — from Nature of Business Activities section)
- status (Active | Cancelled | Suspended)
- cancellation_date (YYYY-MM-DD | null)

GSTIN validation: first 2 digits = state code, chars 3-12 = PAN, char 13 = entity number, char 14 = Z, char 15 = checksum. Verify format is correct.

Generate a Video KYC question script per RBI guidelines (Master Direction on KYC, 2016 updated 2023).

Customer profile:
- Product applying for: [SAVINGS_ACCOUNT | CREDIT_CARD | LOAN | DEMAT]
- Customer type: [NEW | EXISTING_LOW_RISK | RE_KYC]
- Documents to be verified in video: [LIST_DOCUMENTS]

Generate:
1. Liveness check instruction (ask customer to perform specific action)
2. Identity verification questions (5 questions the agent should ask — must match document data without being guessable from public info)
3. Document display instructions (how to hold Aadhaar, PAN for camera verification)
4. Consent statement (RBI-compliant consent for recording and data storage)
5. Rejection criteria checklist (what the agent should look for)

Format as a structured script the video KYC agent can follow step by step.

Generate a user-friendly KYC rejection message and next-steps guidance.

Rejection details:
- Rejection category (per RBI KYC norms): [DOCUMENT_QUALITY | DOCUMENT_EXPIRED | NAME_MISMATCH | ADDRESS_MISMATCH | PHOTO_MISMATCH | INCOMPLETE_DOCUMENTS | SUSPICIOUS_DOCUMENTS]
- Specific issue: [DESCRIBE_SPECIFIC_PROBLEM]
- Document affected: [DOCUMENT_TYPE]
- Re-submission allowed: [YES | NO | AFTER_30_DAYS]

Generate:
1. Customer-facing rejection message (plain English, no legal jargon, 3-4 sentences)
2. Specific action customer needs to take
3. List of acceptable alternative documents (if original document was the issue)
4. Escalation option text (if customer believes rejection is incorrect)

Tone: Factual and helpful, not apologetic. Don't use phrases like "We regret to inform you" or "Unfortunately".

Check if this KYC document set is complete for the requested product.

Product: [SAVINGS_ACCOUNT | CURRENT_ACCOUNT | HOME_LOAN | PERSONAL_LOAN | CREDIT_CARD | DEMAT]
Customer type: [INDIVIDUAL | PROPRIETORSHIP | PRIVATE_LIMITED | PARTNERSHIP | HUF]
Documents submitted: [LIST_DOCUMENT_TYPES_RECEIVED]

Check against RBI KYC Master Direction requirements and output:
1. Is document set complete? (Yes/No)
2. Missing mandatory documents (list)
3. Missing optional-but-recommended documents (list)
4. Documents that expire within 90 days (flag for renewal)
5. Any document combination that creates a compliance gap

Reference: RBI Master Direction - Know Your Customer (KYC) Direction, 2016 (as amended)

Generate a personalised re-KYC reminder for a customer whose KYC is due for periodic update.

Customer segment: [LOW_RISK | MEDIUM_RISK | HIGH_RISK]
Last KYC date: [DATE]
Re-KYC due date: [DATE]
Preferred channel: [SMS | EMAIL | WHATSAPP]
Customer name: [NAME]
Account type: [SAVINGS | CURRENT]
Bank/NBFC name: [INSTITUTION_NAME]

Generate:
1. [CHANNEL]-appropriate reminder message (SMS: <160 chars; Email: subject + body; WhatsApp: conversational tone)
2. Include: what re-KYC is, why it's required (RBI regulation), what documents are needed, deadline, consequence of non-completion
3. Include a CTA with your re-KYC portal link: [PORTAL_URL]
4. Tone: Informative, not alarming. This is compliance, not a problem.

Analyse this customer's transaction history and narrate any anomalies in plain English for a fraud analyst.

Customer ID: [CUSTOMER_ID]
Account tenure: [X] months
Normal transaction pattern (summary): [DESCRIBE_TYPICAL_BEHAVIOUR]

Recent transactions (last 7 days):
[PASTE_TRANSACTION_LIST]

Identify and describe:
1. Velocity anomalies (unusual frequency or speed of transactions)
2. Amount anomalies (unusually large or structured amounts — e.g., just under ₹50,000 limit)
3. Geographic anomalies (new locations, impossible travel)
4. Beneficiary anomalies (new payees, dormant accounts receiving money)
5. Timing anomalies (transactions at unusual hours for this customer)

Format as a brief analyst note (100-150 words) a human investigator can use to make a decision.

Score the risk of this device fingerprint for a new account creation or login attempt.

Device data:
[PASTE_DEVICE_DATA_JSON]

Risk factors to evaluate:
- Is this a rooted/jailbroken device? (check: root indicators in user agent or device flags)
- VPN/proxy/Tor detected?
- Device previously associated with fraud (from provided blacklist)?
- Emulator or virtual device?
- App version vs expected current version gap (>3 versions behind = suspicious)
- Multiple accounts from same device?

Blacklisted device IDs: [PASTE_LIST]
Account count from this device: [NUMBER]

Output:
- risk_score (0-100)
- risk_level (LOW | MEDIUM | HIGH | CRITICAL)
- triggered_rules (array of rule names)
- recommended_action (ALLOW | STEP_UP_AUTH | MANUAL_REVIEW | BLOCK)
- reason (2 sentences for analyst log)

Analyse this customer support chat transcript for social engineering indicators.

Transcript:
[PASTE_CHAT_TRANSCRIPT]

Detect patterns associated with:
- Vishing/social engineering (caller claiming to be from bank, NPCI, RBI, IT department, police)
- Urgency manipulation ("your account will be blocked", "immediate action required")
- OTP phishing (asking customer to share OTP, "test transaction", "refund processing")
- Screen sharing manipulation (asking customer to install AnyDesk/TeamViewer)
- Money mule recruitment language
- Romance/investment scam indicators

Output:
- threat_detected (bool)
- threat_type (enum from list above | null)
- confidence (LOW | MEDIUM | HIGH)
- specific_phrases_flagged (array of quoted text)
- recommended_action (CONTINUE_NORMAL | FLAG_FOR_REVIEW | INTERRUPT_IMMEDIATELY | BLOCK_TRANSACTION)
- agent_script (what the support agent should say right now if threat is detected)

Analyse these accounts for money mule indicators. This is for internal fraud investigation only.

Account data:
[PASTE_ACCOUNT_SUMMARY_DATA]

Transaction patterns:
[PASTE_TRANSACTION_SUMMARY]

Indicators to check:
- Rapid pass-through: money received and forwarded within minutes/hours
- No retention: account balance consistently near zero after flurry of activity
- Fan-out pattern: one large credit split into multiple small debits to different accounts
- Fan-in pattern: many small credits consolidated into one large debit
- Account opened recently (<6 months) with high transaction volume
- Mismatch between stated purpose/occupation and transaction patterns
- Beneficiaries overlap with known fraud cases

For each account, output:
- mule_probability (LOW | MEDIUM | HIGH)
- pattern_type (PASS_THROUGH | FAN_OUT | FAN_IN | LAYERING | UNKNOWN)
- evidence_summary (3-5 bullet points)
- investigation_priority (1-5)

Analyse this chargeback/dispute claim for friendly fraud indicators.

Original transaction:
- Amount: ₹[AMOUNT]
- Date: [DATE]
- Merchant: [MERCHANT_NAME]
- Category: [MERCHANT_CATEGORY]
- Payment method: [UPI | CARD]
- Device/IP at time of transaction: [DEVICE_DATA]

Customer dispute claim:
- Reason code: [CHARGEBACK_REASON]
- Customer statement: [CUSTOMER_EXPLANATION]

Evidence available:
- Transaction authentication: [OTP_VERIFIED | 3DS | PIN | BIOMETRIC]
- Delivery confirmation: [YES | NO | PARTIAL]
- Previous chargebacks from this customer: [COUNT] in last 12 months
- Customer tenure: [MONTHS]

Evaluate:
1. Legitimacy score (0-100, 100=clearly legitimate dispute)
2. Friendly fraud probability (LOW | MEDIUM | HIGH)
3. Key evidence supporting or undermining the claim
4. Recommended decision: ACCEPT_DISPUTE | REJECT_DISPUTE | REQUEST_MORE_EVIDENCE
5. Reasoning for dispute resolution team (3-4 sentences)

Generate an executive summary of this suspicious account cluster for senior risk review.

Cluster analysis data:
[PASTE_CLUSTER_REPORT_DATA]

The summary should cover:
1. Cluster overview (number of accounts, total exposure in ₹, date range of activity)
2. Connection pattern (how accounts are linked: device, address, phone, beneficiary overlap)
3. Fraud typology (what scheme does this resemble: bust-out, account takeover, synthetic identity, mule network)
4. Financial exposure (confirmed fraud ₹ | at-risk ₹ | recovered ₹)
5. Recommended immediate actions (accounts to freeze, transactions to hold, regulatory reporting obligations)
6. FIU-IND reporting: Is a Suspicious Transaction Report (STR) filing required? (threshold: any transaction suggesting proceeds of crime or financing terrorism)

Length: 250-300 words. Written for a Chief Risk Officer — precise, no hedging, actionable.

Summarise this RBI circular and extract all action items required for a [BANK | NBFC | PAYMENT_AGGREGATOR | FINTECH].

Circular text:
[PASTE_RBI_CIRCULAR_TEXT]

Extract:
1. Subject and reference number
2. Effective date / compliance deadline
3. Who it applies to (entity type)
4. Summary (3-5 bullet points, plain English)
5. Action items required (numbered list, sorted by deadline)
6. Penalties for non-compliance (if stated)
7. Supersedes / amends which previous circulars

For each action item, include:
- Action description
- Responsible team (suggested: Compliance | Technology | Operations | Legal | HR)
- Deadline
- Estimated complexity (Low | Medium | High)

Generate a Suspicious Activity Report (SAR) narrative for FIU-IND filing.

Transaction details:
[PASTE_SUSPICIOUS_TRANSACTION_DATA]

Customer profile summary:
[PASTE_PROFILE_SUMMARY]

Investigation findings:
[PASTE_INVESTIGATOR_NOTES]

Generate a SAR narrative that:
- Opens with the nature of suspicious activity (1 sentence)
- Describes the account and customer background (2-3 sentences)
- Details the specific suspicious transactions in chronological order
- Explains why this is suspicious (what normal behaviour looks like vs what was observed)
- Lists any connected accounts or entities
- States what action has been taken (account frozen | transaction blocked | none — pending SAR)

Requirements:
- Follow PMLA 2002 and FIU-IND SAR filing guidelines
- Factual and objective tone — no speculative language
- 300-500 words
- Do not include customer PII in this output (use masked identifiers)

Classify this customer complaint for routing and TAT tracking per RBI norms.

Complaint text: [PASTE_COMPLAINT]
Channel received: [BRANCH | CALL_CENTRE | EMAIL | APP | SOCIAL_MEDIA | RBI_BANKING_OMBUDSMAN]
Customer segment: [RETAIL | SME | CORPORATE]
Product: [SAVINGS | CURRENT | LOAN | CARD | UPI | WALLET]

Classify by:
1. Category (Unauthorized transaction | Service failure | Fees dispute | KYC issue | Account closure | Digital banking | Loan servicing | Other)
2. Severity (P1: potential fraud/regulatory | P2: financial loss | P3: service complaint | P4: query)
3. Required TAT per RBI Banking Ombudsman Scheme (P1: immediate | P2: 7 days | P3: 30 days | P4: 7 days for reply)
4. Routing: which team should handle this?
5. Regulatory escalation required? (If complaint already filed with RBI Ombudsman — mark REGULATORY_ESCALATION)
6. Suggested response template category

Output: JSON for CRM system ingestion

Generate a human-readable audit trail explanation for this sequence of system events.

System log:
[PASTE_AUDIT_LOG_JSON_OR_TEXT]

Context:
- System: [PAYMENT_SYSTEM | KYC_SYSTEM | CORE_BANKING | FRAUD_ENGINE]
- Event under investigation: [DESCRIBE_THE_EVENT_OR_TRANSACTION]
- Audience: [INTERNAL_AUDITOR | REGULATOR | LEGAL_TEAM]

Translate the technical log into:
1. Timeline narrative (what happened, in what order, at what time)
2. Actor identification (who or what system initiated each action — human operator, automated system, customer, API caller)
3. Data changes made (what was modified, from what value to what value)
4. Authorization chain (was each action properly authorized? by whom?)
5. Anomalies in the audit trail (missing events, out-of-sequence actions, unusual actor/IP)

Length: As needed to cover all events. Prioritise accuracy over brevity.