Using an AI Agent to Read Referral Notes and Flag Signups

A referral review agent should read three things at once, because each alone produces too many false alarms.

The first is the free-text note itself, meaning the message the referrer typed when they invited the friend (or the note that arrives with the signup). Fraud rings reuse the same phrasing because they are the same person or the same script. A model spots this far better than a keyword list, because it can catch paraphrases and template fill-ins.

The second is device and network signals: device fingerprint, IP address, browser and operating system combination, and whether that combination already appears against another account. This is where rings break: ten signups from one device or one small IP range are not ten friends.

The third is email patterns: disposable domains, domains registered very recently, plus-addressing that routes many signups to one inbox, and display names that follow a predictable pattern. Google's own documentation on campaign tagging shows how much identity information rides along in a URL, including source, medium and campaign values that identify where a visitor came from (Google Analytics). Referral links built this way give you a structured field to group signups by referrer code, which is exactly what you need to see clusters forming.

It is tempting to treat a high score as a verdict. It is not, and a recent research paper explains why. Researchers built a benchmark of 28 online fraud scenarios and 2,800 posts, then showed that LLM agents can collaborate on fraudulent behavior, that collaboration amplifies the risk, and, importantly, that malicious agents can adapt to environmental interventions (Ren et al., arXiv). In plain terms: the adversary changes behavior when your filters change, so no static rule set stays accurate. The same paper proposes practical mitigations, including content-level warnings on fraudulent posts and using LLMs as monitors to block potentially malicious agents.

This is the strongest argument for keeping the agent in an advisory role. A score is a question the agent asks a human, not an answer it enforces. It also means you should watch the model's own outputs for drift. If average score across your referral population creeps upward without a matching rise in confirmed fraud, the agent is probably learning to be suspicious rather than accurate.

A fraud-review agent should therefore produce a scored record with reasons attached, staged for a person to approve, rather than a final label. That keeps the human as the last check before money moves or an account is closed.

A vague prompt returns a vague verdict. A usable prompt produces a fixed schema the reviewer can read in five seconds. Here is a working structure you can adapt.

You are a referral risk reviewer. You do not approve or reject anything.
You score each referral record on a 0 to 100 risk scale and explain your reasons.

For each record, read:
1. referral_note: the free text the referrer wrote
2. note_cluster_sample: up to 5 other referral notes sharing the same
   first 8 words or the same referrer code
3. device: fingerprint hash, IP, browser, OS, account_count_on_device
4. email: domain, domain_age_days, is_disposable, plus_alias_used
5. timing: seconds between invite click, signup, and first payout request

Output JSON with these fields:
- risk_score: integer 0 to 100
- reasons: array of short strings, each tied to a specific field above
- cluster_id: if the note resembles the cluster sample, name the pattern
- confidence: low, medium or high
- recommended_action: allow, hold_for_review, or block

Scoring guidance:
- Reused or templated phrasing across distinct referrers: strong signal
- Same device fingerprint across accounts with different names: strong signal
- Disposable email domain on its own: weak signal, note it, do not escalate
- Fast signup-to-payout time on its own: weak signal
- Two or more strong signals: score at least 70 and use hold_for_review

Never recommend block for a record with fewer than two strong signals.
If the record is incomplete, say so in reasons and set confidence to low.

Three design choices carry most of the value. First, the agent sees a cluster sample rather than the single note, because similarity is only visible in comparison. Second, the prompt defines a minimum-evidence rule for blocking, which forces the model to stop at "hold" when it is guessing. Third, it demands the reasons array, which is what the human reviewer reads first.

You can run this prompt against any serious text model. If you want to test several models side by side without wiring separate integrations for each vendor, Quanta Inference gives you text, image and embedding models through one OpenAI-compatible API key (https://quantaintelligence.ai/inference).

Thresholds should be derived from your payout size and your review capacity. Here is a worked example using round numbers you can replace.

Assume your program pays 20 USD to the referrer and 20 USD to the new customer, so each fraudulent signup costs 40 USD if paid. Assume you receive 5,000 referral signups a month and an experienced reviewer can clear 60 records an hour. Assume your fraud baseline is 6%, or 300 fraudulent signups monthly, and that a well-set agent catches 80% of them.

At these assumptions the reviewer sees 200 records a month, roughly three and a half hours of work, and catches 240 of the 300 fraudulent signups, avoiding 9,600 USD in payouts. If your false positive rate at the review band is 30%, you are also slowing down 60 legitimate signups a month, which costs goodwill and some conversion. That trade is usually worth it, but it must be a deliberate choice, not an accident.

The decision rule: set the review threshold so that the cost of one false positive (lost referral value plus review minutes) is comfortably smaller than the expected value of one caught fraud, then lower the threshold only if your queue has slack. Celerant's guide to referral programs makes the related point that a program's success is measured on tracking, so build the measurement into the workflow rather than bolting it on after the thresholds are fixed (Celerant).

The reviewer's screen should show the score, the reasons, and the raw record side by side. Three approval outcomes are enough: approve payout, reject and flag the referrer, and hold pending more information. A fourth, escalate to investigation, is only worth adding once you have a queue large enough to justify it.

Keep the human in the decision for any action that costs the customer money or access. The agent can draft the reviewer note, summarize the cluster evidence, and suggest a rejection reason. It should not close an account or claw back a reward on its own. The collusion research above is the reason: systems that adapt to your defenses will eventually find your defenses, and a person reviewing the evidence is the last check before a legitimate customer is punished. The authors of that study specifically recommend using LLMs as monitors rather than as autonomous enforcers, which matches this division of labor (arXiv).

Two operational rules help here. First, log every agent decision and every human override with the reasons, so you can measure the agent's precision against human judgment each month. Second, publish a plain-language explanation in your program terms about what gets reviewed and why, so honest customers who trigger a check are not surprised. Extole's guide to cookieless referral tracking notes that first-party and server-side methods built on clear consent provide a cleaner measurement path, and the same consent logic applies to using device data in fraud review (Extole).

If you would rather start from a working reviewer flow than from a blank file, Quanta can build the intake form, the scoring step and the approval queue with you (https://quantaintelligence.ai/).

Start in shadow mode. For two weeks, let the agent score every signup and write its recommendation to a log, but keep paying exactly as you pay today. At the end of the period, compare its recommendations to what actually happened: which flagged signups later turned out to be fraudulent, and which allowed signups triggered chargebacks or duplicate-device alerts.

Then enable the review band only, and only for payouts above a size you choose. Small rewards can stay fully automated because the loss per event is low. As the agent's measured precision improves, widen the band downward.

Finally, revisit the signals quarterly. Ring tactics change, device fingerprints get spoofed, and email providers change their alias behavior. The agent's prompt and the cluster sample it sees should change with them. That maintenance loop is the difference between a fraud filter that works and one that quietly stops working.