Free Fraud Reporting Chatbot: Structured Intake, Fast Triage

Despite the name, this template is a fraud reporting intake, not a fraud detection engine. That distinction is the most important thing to understand before you deploy it, and it should shape every word of copy you put around it. The flow does not score transactions, analyse behaviour, check anything against a database, or decide whether fraud occurred. What it does — and does well — is take a report from a distressed person in a fixed, complete order, attach evidence to it, email a case record, and get a specialist on the line.

That is a real problem worth solving. Fraud reports that arrive by phone or free-text email are chronically incomplete: no date, no amount, no indication of whether personal data was exposed, no evidence attached. Every gap means a call back, and every call back costs a day at the point when days matter most. A fifteen-node conversation that asks the same seven questions every time produces a case file an investigator can actually work from.

The flow is built in the chatbot builder and includes an email node that generates a case reference and a human handover node configured at high priority.

1. Welcome. "Welcome to the Fraud Detection and Reporting System. We take all reports seriously and will investigate thoroughly. Please provide as much detail as possible to assist our investigation." The tone is right — serious, no emoji, no upsell.

2. Fraud type. Five options — Credit Card Fraud, Identity Theft, Phishing Attempt, Suspicious Transaction, Other — stored as fraud_type. All five converge on the same intake, which is the correct design: the questions an investigator needs are the same regardless of category, and forking here would only create five copies of the same sequence to maintain.

3. Date noticed. Free text: "On what date did you first notice the fraudulent activity?", into fraud_date. First-noticed rather than occurred, which is the answer a reporter can actually give.

4. Description. An open field for a detailed account of the activity, into fraud_details, acknowledged with "Thank you for providing this information." This is where the narrative that investigators read lives.

5. Amount. A validated number with a currency prefix and a floor of zero, into fraud_amount, with explicit instructions to enter 0 if not applicable. The instruction matters — phishing attempts often involve no loss at all, and without it the field gets skipped or filled with noise.

6. Personal data exposure. "Do you believe your personal information has been compromised?" with three answers — Yes, No, Unsure — into personal_info_compromised. Including "Unsure" is the right call; forcing a binary on a frightened person produces bad data. This is often the single most triage-relevant field in the whole report.

7. Contact details. Email with validation into contact_email, then phone into contact_phone. Both, not either — fraud follow-up needs a voice channel.

8. Evidence upload. A file node inviting screenshots or documents, into evidence_file. Capturing evidence at the moment of reporting, while the reporter still has the phishing email open, is worth more than requesting it later.

9. Case email. An email node sends confirmation to the reporter, blind-copies a fraud reports mailbox, uses a subject line that builds a case reference from the fraud type and a timestamp, and includes the full chat transcript. The transcript inclusion is what turns this from a notification into a case file.

10. Confirmation. The bot tells the reporter their report is submitted, that a confirmation email with a case number is coming, and that a specialist will contact them within 24 to 48 hours.

11. Escalation. "Do you have any additional questions or concerns?" A yes routes to a human handover node set to high priority, automatic assignment using a least-busy strategy, a five-minute maximum wait, handover email and sound alerts enabled, and tags of fraud_report and additional_questions. The fallback message directs the reporter to a fraud hotline number.

12. Close. A final message repeating the hotline number for urgent concerns.

Banks, credit unions and card issuers are the obvious audience — this is a structured front door for the fraud line that keeps low-urgency reports off the phone queue while routing the urgent ones to a person faster than a phone tree would.

Fintechs, payment processors and wallet providers get an intake that works at any hour, which matters because fraud is discovered at 2am as often as at 2pm. E-commerce marketplaces can use it for seller and buyer fraud reports, where the same completeness problem exists.

Outside financial services, the structure transfers cleanly to internal whistleblowing and misconduct reporting, insurance fraud referrals, and any incident reporting workflow where an organisation needs a complete, timestamped, evidence-backed record from a distressed reporter.

Related flows: the banking FAQ chatbot handles the general enquiries that would otherwise clutter this flow, the Credit Card Application bot covers acquisition, and the debt collection chatbot covers another sensitive customer conversation. See all of them at finance and banking templates.

1. Replace every placeholder before launch

The template ships with an example fraud mailbox and an example hotline number, and both appear in customer-facing text. A fraud bot that gives out a fake hotline number is worse than no bot at all. Change the email node's blind-copy address to your real fraud intake mailbox, and replace the phone number in both the handover fallback and the closing message.

2. Fix the case reference

The subject line builds a reference from the fraud type and a timestamp. That is a reasonable default, but it is not a case ID your case management system recognises. Either adopt it as your convention or replace it by generating an ID upstream and passing it in through a webhook. Whatever you choose, the reference in the email must be the one your agents can search.

3. Route the report into your systems, not just an inbox

An emailed transcript is a good start; a case record is better. Conferbot's webhook node pushes the whole structured payload — type, date, description, amount, exposure flag, contact details, evidence — into your own case management platform. Zapier reaches 2,000+ apps if your fraud tooling is elsewhere, and HubSpot or Zoho CRM work if reports are handled alongside customer records. Note that webhooks and API access require a paid plan; the website widget and the email node work on Free.

4. Staff the high-priority queue honestly

The handover is set to high priority with a five-minute maximum wait. Live chat handover and the unified inbox are included on every plan, including Free, so the capability is not the constraint — coverage is. Decide who is on the fraud queue and when, set the wait to match, and write the fallback message around what you can actually deliver. Handover email and sound alerts are already enabled, which helps agents notice.

5. Branch the "personal information compromised" answer

This is the highest-value edit in the whole template. A reporter who answers Yes needs immediate, specific guidance — freeze the card, change passwords, contact the credit bureaux — and should go straight to handover rather than to a generic 24-to-48-hour message. One branch here materially changes outcomes.

6. Review the copy with compliance

The shipped confirmation promises an investigation and a specialist contact within 24 to 48 hours. Make sure that is a commitment your operation can meet, because in a regulated context a stated service level is a stated service level. Adjust the wording to match your real process before anyone sees it.

Add an urgency triage at the top. One question — "Is money currently leaving your account?" — that routes straight to handover on a yes. Everything else can wait for the full intake; an in-progress theft cannot.

Make the date a calendar node. Free-text dates arrive in every format imaginable and cost investigators time. A calendar node gives you a clean value you can also use to compute how long ago the activity started.

Branch the description by type. Keep the single intake, but change the prompt text per fraud type: a phishing report should be asked for the sender address and what was clicked, a suspicious transaction for the merchant name and card last four. Same node count, far better reports.

Ask about other affected accounts. Fraud rarely stops at one product. A yes/no with a follow-up saves a callback.

Capture a preferred callback window. A calendar or choice node here reduces the phone tag that follows every fraud report.

Acknowledge the emotional register. Add a short, human line after the description node. People reporting fraud are frequently frightened or embarrassed, and a bot that reads as a form increases the drop-off rate at exactly the wrong point.

Add a status-check entry point. A second flow that takes a case reference and returns a status removes a large share of the follow-up contacts that fraud teams field.

Conferbot does not gate channels by plan, so this flow can sit on every surface your customers use. The website widget is the primary home — put it on your security page, your "report fraud" page and inside your logged-in area, where a customer who has just spotted a strange transaction is already looking.

WhatsApp is a strong second channel: customers often discover fraud away from a computer, and a reporting path on their phone gets the report in while the details are fresh. Messenger and Instagram matter if your brand's social accounts receive fraud complaints — which they do, publicly, and moving those into a structured private flow is worth doing. Telegram, LINE, Discord, Microsoft Teams and the mobile SDK are available too; Teams in particular suits the internal misconduct-reporting variant of this flow.

One channel caution: messaging platforms are not confidential in the way a logged-in banking session is. Keep the flow to what the reporter volunteers about the incident, never ask for full card numbers, passwords or security codes, and say so in the copy.

The free plan covers 600 conversations a month and one chatbot. Most institutions will want a paid plan from $19/month for webhooks, API access and removal of Conferbot branding; Business adds SSO and the audit trail, which matters if fraud intake sits inside a controlled environment. See pricing.

Never describe this as fraud detection. It detects nothing. Marketing it as detection sets an expectation you cannot meet and, in a regulated context, is a claim you do not want to have made. Call it fraud reporting or fraud intake.

Never ask for credentials. No full card numbers, no PINs, no passwords, no one-time codes. Fraudsters imitate fraud lines, and a legitimate bot that asks for a security code trains customers to hand them over. Add an explicit line saying you will never ask for these.

Do not give a legal or regulatory verdict. The flow should not tell a reporter whether they will be reimbursed, whether the activity is legally fraud, or what their statutory rights are. Those answers depend on jurisdiction, product terms and investigation findings. Point to your real process instead.

Mind the data you are now holding. A completed report contains a narrative, an amount, contact details and uploaded evidence about a person's financial life. Retention, access control and deletion all apply. On the Business plan, the audit trail helps evidence who accessed what.

Within those limits this is one of the most immediately useful finance templates available in 2026 — not because it is clever, but because complete, timestamped, evidence-backed reports are exactly what fraud teams never get.