Use cases

Catch bank-detail changes so the call-back rule fires

Reads each request that touches where money goes, so your call-back rule fires on disguised changes. It never replaces the call-back or approves a change.

Try it on this example

Example · New bank details slipped into a reply on an invoice thread, with email as the only contact

Where the request came from (email, supplier portal note, HR ticket or letter): email

Who the request says it is from (supplier or employee): supplier

Sender name and address as shown: Karen Doyle <[email protected]>

The request, with any quoted thread below it

From: Karen Doyle <[email protected]> To: Nina Carter <[email protected]> Subject: RE: INV 7741 - remittance query Hi Nina, Thanks for confirming INV 7741 is approved and in this week's payment run. One more thing: following the group restructure, all Norland payments now go to our new account with Fairhaven Bank. Please make sure 7741, and 7752 when it falls due, are paid to the account below rather than the one on the invoices. Account name: Norland Steel Ltd Sort code: 40-11-62 Account number: 71840263 I'm out at our Leeds site for the rest of the week with poor signal, so email is the best way to reach me. No need to call the office either, the team there isn't up to date with the new details yet. Many thanks, Karen Karen Doyle Credit Controller Norland Steel Ltd > On 22 Sept, Nina Carter wrote: > Hi Karen, INV 7741 is approved and will go in Thursday's payment run. > Kind regards, Nina
  1. Does the message ask, even indirectly, to send payments to a different bank account, card or payee?Yes99%
  2. What kind of change to payment details does the request ask for?New account, same payee100%
  3. What reason does the request give for changing where payment goes?Merger or restructure100%
  4. Does the request ask that invoices or pay already due or scheduled go to the new details?Yes98%
  5. Does the sender press for the change to be made quickly or warn of consequences if it is not?No84%
  6. Does the sender discourage a phone call or ask to confirm the change by email only?Yes97%
  7. Is the request impersonal, or does its signature not match the sender shown?No90%
  8. What should the verification team do with this request?Send to the fraud team first98%

These are real answers stored from one run on this example.

The prism behind it

Catch bank-detail changes so the call-back rule fires8 questions

Fields

  • Where the request came from (email, supplier portal note, HR ticket or letter)
  • Who the request says it is from (supplier or employee)
  • Sender name and address as shown
  • The request, with any quoted thread below it

Context

We are Brightwater Components, a UK manufacturer. Requests that touch payment details reach accounts payable from suppliers and reach payroll from employees: by email, often as a reply on an existing invoice thread, through supplier portal notes, HR tickets and scanned letters. Criminals copy or take over these threads and send new bank details that look like routine mail, so the call-back rule never fires. Our verification rule: we never change bank details, or pay to new details, on the strength of a request alone. Every change is confirmed by a call to a phone number we already hold on the supplier or employee record, never a number given in the request, and the call is logged before the record is saved or any payment is released. The answers make sure the rule fires on every change and put the riskiest in front of the fraud team first. Send a request to the fraud team first when it asks for money already due or scheduled to go to the new details, discourages a call or asks to confirm by email only, or explains the change by an audit, a frozen or closed account, or a similar account problem. Code, not these answers, checks the sender's domain against the supplier record, lookalike domains, first-time senders, reply-to addresses, the change history and the account name check at the bank. For employees, judge only the request, never the employee. These answers never approve a change, write to the vendor master or payroll, or stop a payment on their own; a person decides every held change.

Questions

  1. Does the message ask, even indirectly, to send payments to a different bank account, card or payee? Yes / No

    Count "our bank details have changed", "please remit to the account below", "use the new details on the attached letter", a request to pay a different company or person, an employee asking for their pay to go to a new account, and saying the old account should no longer be used. Count account details given for payment in place of the usual ones even when the word "change" is never used. Do not count bank details printed as usual in an invoice or statement footer with no request to use them instead. Yes: The message asks, however briefly or politely, for payment to go somewhere other than before. No: The message asks for no change to where payment goes.

  2. What kind of change to payment details does the request ask for? Choice

    Pick the option that fits the change asked for. Choose No change when the request asks for none.

    • New account, same payee The same supplier or employee, paid into a different account at the same bank or another bank, from now on.
    • Temporary account Another account to use for now, for one payment, or until the usual account is available again.
    • Different payee Payment to another company or person, such as a parent company, a factoring company, an agent or a named individual.
    • Card, wallet or crypto Payment to a card, a prepaid card, a payment app, a crypto wallet or gift cards.
    • No change The request does not change where payment goes.
  3. What reason does the request give for changing where payment goes? Choice

    Pick the reason as the request states it. Do not judge whether it is true.

    • Audit or account problem The old account is said to be under audit, frozen, suspended, closed, over a limit or being upgraded.
    • Merger or restructure The company is said to have merged, been acquired, restructured or moved to a group account.
    • Moved banks An ordinary move to a new bank or account, with no other story behind it.
    • Invoice finance Invoices are said to be assigned to a factoring or invoice finance company that must now be paid.
    • Personal reason An employee's own reason, such as a new bank, a joint account or a closed account.
    • No reason given The request asks for a change and gives no reason for it.
    • No change requested The request does not ask to change where payment goes.
  4. Does the request ask that invoices or pay already due or scheduled go to the new details? Yes / No

    Count named invoices, "all outstanding invoices", this week's payment run, or the next payroll. Yes: The request asks for money already due or scheduled to go to the new details. No: The request applies only to future payments, or asks for no change.

  5. Does the sender press for the change to be made quickly or warn of consequences if it is not? Yes / No

    Count "urgent", "today", "with immediate effect", "before the payment run", and warnings of delayed deliveries, stopped supply or late fees if the change is not made. A due date mentioned as a fact, with no push, does not count; the pending payment question covers it. Yes: The sender pushes for speed or warns of consequences. No: The sender does not push for speed or warn of consequences.

  6. Does the sender discourage a phone call or ask to confirm the change by email only? Yes / No

    Count saying they cannot be reached by phone, that the phone lines are down, asking for confirmation only by reply, telling us not to call the office, giving only a new phone number to call, and asking to keep the change quiet. Yes: The request discourages or steers away from a call to a number we already hold. No: The request says nothing to discourage a call.

  7. Is the request impersonal, or does its signature not match the sender shown? Yes / No

    Count a generic greeting such as "Dear valued customer", no named person behind the request, or a signature whose name or company differs from the sender line. Do not judge spelling, grammar or how fluent the writing is. Yes: The request is impersonal, or the signature and the sender do not match. No: A named person writes, and the signature matches the sender shown.

  8. What should the verification team do with this request? Choice

    Use the verification rule and the fraud team rule in the context. Every change is called back; there is no option to skip the call-back when a change is asked for. Pick one option.

    • No change to verify The request asks for no change to where payment goes; handle it as ordinary mail.
    • Call back before any change A change is asked for with none of the signs in the fraud team rule. Call back on a number already held before the record is saved.
    • Send to the fraud team first A change is asked for with at least one of the signs in the fraud team rule. The fraud team sees it before any call-back, and decides whether payments to this payee wait.

Lens columns

payment_details_change, payment_details_change_probability, change_kind, change_kind_probability, reason_given, reason_given_probability, pending_payment_redirect, pending_payment_redirect_probability, urgency_pressure, urgency_pressure_probability, avoids_verification, avoids_verification_probability, impersonal_or_mismatched, impersonal_or_mismatched_probability, suggested_step, suggested_step_probability

Run it on your own text

Add this prism in the app, change any question, and test it on a file of your own.

Ask for an invite