The prompt
Score 10 of 10, Excellent
Use it when A supplier has asked you to send future payments to a new bank account, and you want the request checked for fraud signs and a call-back plan before anyone pays.
- {{request}}
- {{supplier_on_file}}
- {{our_controls}}
- {{payments_due}}
- {{handler}}
- {{approver}}
Full prompt and why it works
System prompt
You help finance teams check requests to change a supplier's bank details, a common route for payment fraud through hijacked or imitated email. You point out warning signs in the request, set out verification steps that use only contact details already on file, and never treat a request as safe because it looks genuine.
User message
<request> {{request}} </request> <supplier_on_file> {{supplier_on_file}} </supplier_on_file> <our_controls> {{our_controls}} </our_controls> <context> Payments due to this supplier soon: {{payments_due}} Who in our team handles supplier record changes: {{handler}} </context> Review the bank detail change request above for {{approver}}, so that nobody updates the supplier record or releases a payment until the change has been confirmed with the supplier through contact details we had before this request arrived. Produce: 1. What the request asks for, in two sentences: who it claims to be from, what should change and from when. 2. Warning signs: a table with the columns Sign, Evidence (quoted from the request), Why it matters, Status (present, not present, cannot tell from the text). Check at least: a sender address or domain that differs from the one on file, even by one character; a reply-to address that differs from the sender; urgency or pressure; a request to keep it confidential or skip normal steps; a new account in a different name or country from the supplier; timing just before a large payment; a change in tone, signature or letterhead; and attachments or links. 3. Verification steps, numbered: call the supplier on the phone number in our records, not one in the request; speak to a contact we have dealt with before; confirm the old and new details and the reason for the change; record who confirmed it and when; get the second approval our controls require. 4. Who approves the change under our controls, and what must be recorded. 5. A short email to the supplier, under 100 words, sent to the address on file rather than as a reply, saying we received a request and will call to confirm before changing anything. 6. If the request looks fraudulent: telling {{handler}} and anyone else our controls name, keeping the original email with its full headers, and contacting our bank at once about any payment already sent. <example> The form of one row: "Sender domain | the sender's domain adds '-payments' to the domain in our records | look-alike domains are a common sign of an imitated supplier | present". This shows the form only. </example> Keep it under 600 words. The tone should be calm and practical. Rules: - Never suggest using a phone number, email address, link or document from the request to verify it, because whoever sent a fraudulent request controls all of them. - Do not conclude the request is genuine, even if no warning signs are present: a supplier's own mailbox can be taken over, so the call-back is required whatever this review finds. - Do not repeat full bank account or routing numbers; refer to accounts by their last four digits. - Do not accuse the supplier or anyone in our team. If our records have no phone number or known contact for this supplier, say so at the top and recommend that the change waits until one is found from an independent source, such as an earlier signed contract or the supplier's official website reached by typing its address.
Variables
- {{request}}
- The request exactly as received, with the sender's address, reply-to address and date. Mask the new account number to its last four digits.
- {{supplier_on_file}}
- What your supplier record shows from before the request: name, usual email domain, phone number and known contact, and the last four digits of the current account.
- {{our_controls}}
- Your rules for changing supplier bank details: who can make the change, who approves it, what must be recorded.
- {{payments_due}}
- Payments due to this supplier in the next few weeks, with amounts and dates, or "none".
- {{handler}}
- Who handles supplier record changes, for example "the accounts payable lead".
- {{approver}}
- Who approves the change, for example "the finance manager".
Why it works
- What to avoid. Contact details in the request are never used to verify it, because whoever sent a fraudulent request controls every one of them.
- What good looks like. No request is declared genuine, since a supplier's real mailbox can be compromised; the call-back to a number on file is required either way.
- If unsure. With no phone number on file, the change waits until a contact is found from an independent source.