HELP US MAKE DOTSUPER MORE USEFUL

Can we learn from your visit?

Privacy notice

LTRLS Learning Through Real-Life Scenarios

The CEO called. Would you approve the payment?

Handle six fictional payment decisions under pressure. Verify changed instructions, preserve approvals and respond promptly when a transfer may have gone to the wrong account.

6 fictional cases20–30 minutes solo; 45–60 with a team (estimates)General business controls; reporting routes depend on location context
Start experience

No account needed. Work alone or discuss with a team.

A payment request moves through independent verification and approval.
dotSuper. Original illustration for this learning experience.. Original dotSuper material. Contact dotSuper for reuse permissions. Third-party sources retain their own terms.

What you will practise

Make the trade-off visible.

Verify the beneficiary and payment instruction through independently established channels. Keep approval authority intact under urgency, and contact the bank promptly when a transfer may be fraudulent.

  • Separate a familiar identity cue from verified transaction authority.
  • Handle beneficiary changes and approval exceptions through established controls.
  • Respond to a suspected transfer without assuming recovery is guaranteed.

Built for the people making the call

Finance teamsBusiness ownersProcurement teamsPeople who approve or request payments

Original fictional educational cases. All companies, prices, volumes and outcomes are illustrative. Sources support the stated principles, not claimed customer results. Completion is a learning record, not a professional assessment.

From the exercise to the business

What a better decision could change.

What you will learn

Verify a transaction without relying on confidence, familiarity or executive pressure.

Potential business value

Reduce exposure to misdirected payments while maintaining a workable process for legitimate urgent transactions.

How the value could happen

Known request route → beneficiary verification → authorised approval → payment record → rapid exception response.

Measures to examine

  • Beneficiary changes independently verified before release
  • Documented approval exceptions
  • Time from suspected transfer to bank contact
  • Legitimate payment delays caused by verification gaps

Keep these limits in view

  • A completed exercise cannot establish fraud readiness.
  • Do not claim avoided losses from the number of suspicious messages.
  • Do not turn staff into audio-forensics specialists.

A useful next step: Walk through one fictional beneficiary-change request using the organisation’s current roles and trusted contacts.

Explore the companion method
  1. 01

    Read the situation

    Identify the purpose, people and consequences.

  2. 02

    Make your choice

    Confirm a response before opening the reasoning.

  3. 03

    Question the control

    Discuss what would need to change in a real workflow.

  4. 04

    Leave with a card

    Record an owner, evidence, approval conditions and a stop point.

LTRLS / Practise before the real decision

A situation. A choice. A better question.

A familiar voice and a plausible invoice arrive near the bank cutoff. Decide what establishes authority to pay and how to keep legitimate work moving.

6 fictional cases20–30 minutes solo; 45–60 with a team (estimates)No account, no countdown

Progress and notes stay in this page’s memory. Refreshing, leaving or closing the page loses them. Use anonymous examples and roles.

Running this with a team?
  • Use text and fictional names. A participant should not need to recognise a voice or visual artifact.
  • Ask what exactly has been verified: identity, beneficiary, amount, purpose or authority.
  • Avoid blame. Evaluate the process and its urgent route.

Prefer to read?

The complete case notes.

The same situations and reasoning, without the interactive flow.

Open all 6 cases

Case 01

A familiar voice changes the destination

A voice message sounding like the CEO requests an AED 84,000 supplier payment today. The invoice matches a real purchase. The message provides new account details and asks you to use them before the bank cutoff. Those details are not in the approved supplier record.

What should happen before release?

  • Ask for a second voice message confirming the account.
  • Pay because the invoice matches a real purchase.
  • Verify the changed beneficiary through established contacts and apply the normal transaction approvals.
  • Run an audio detector and pay if it labels the voice genuine.

Recommended response for this scenario

Verify the changed beneficiary through established contacts and apply the normal transaction approvals.

The invoice supports the purchase, not the new bank destination. Verify the change independently using the agreed process. A convincing voice cannot replace beneficiary verification and authorised approval. Record the result before any release.

Why each choice matters

Ask for a second voice message confirming the account.
Repeating the same unverified channel does not establish a trustworthy change.
Pay because the invoice matches a real purchase.
A legitimate debt does not validate a changed beneficiary.
Verify the changed beneficiary through established contacts and apply the normal transaction approvals.
This checks the specific instruction at issue while preserving the approval process.
Run an audio detector and pay if it labels the voice genuine.
A detector result does not establish transaction authority or the beneficiary’s legitimacy.

Practical control: Treat a changed payment destination as an explicit exception with a verification owner and a release condition.

Discuss: Which fact does the valid invoice establish, and which fact is still missing?

Case 02

The callback number is in the message

The supplier email includes a phone number for confirming its new bank details. A colleague calls it and receives a confident confirmation. The supplier master record contains a different contact number established before this request.

What does the callback establish?

  • It remains insufficient; use the independently established supplier contact route.
  • The change is verified because two people heard the confirmation.
  • The change is verified if the number also appears in the same email signature.
  • It is sufficient for a small test payment before the full transfer.

Recommended response for this scenario

It remains insufficient; use the independently established supplier contact route.

The callback stayed inside the unverified request. Use contact details established independently before the change, following the organisation’s supplier-verification procedure. Confirm the relevant bank instruction and record the result. Do not substitute repeated reassurance for independent evidence.

Why each choice matters

It remains insufficient; use the independently established supplier contact route.
The new message supplied both the instruction and the supposed verification path.
The change is verified because two people heard the confirmation.
More listeners do not make the source of the callback independent.
The change is verified if the number also appears in the same email signature.
That still relies on information controlled by the same unverified request.
It is sufficient for a small test payment before the full transfer.
A test payment to the unverified destination can still lose money and does not prove entitlement.

Practical control: Keep trusted verification contacts separate from the message that requests the change.

Discuss: What would you do if the established contact cannot be reached before the cutoff?

Case 03

The approver is travelling

The payment is legitimate and its destination verified. Policy requires two authorised approvals. One approver is travelling. An approved substitute exists but has not been contacted. The requester asks you to split the transfer into smaller amounts to bypass the second approval.

Which response preserves both control and useful progress?

  • Split the transfer because the total obligation is already known.
  • Release now and obtain the second approval after the bank cutoff.
  • Suspend all supplier payments until the travelling approver returns.
  • Use the approved substitute or documented urgent route before releasing the transfer.

Recommended response for this scenario

Use the approved substitute or documented urgent route before releasing the transfer.

Use the authorised substitute. Keep the payment intact and the required approvals visible. If no approved route can be completed in time, escalate the delay and business consequence. Urgency needs a workable path that does not silently remove the control.

Why each choice matters

Split the transfer because the total obligation is already known.
This circumvents the control through transaction structure.
Release now and obtain the second approval after the bank cutoff.
Retrospective approval does not provide the required pre-release decision.
Suspend all supplier payments until the travelling approver returns.
An authorised substitute exists, so a broad suspension is unnecessary.
Use the approved substitute or documented urgent route before releasing the transfer.
This respects the actual authority structure while allowing legitimate urgency.

Practical control: Document alternate approvers and cutoff escalation in advance. Record who approved the actual transaction.

Discuss: Who can accept a missed deadline when the required approval is unavailable?

Case 04

The transfer may already be gone

A colleague reveals that a transfer was released fifteen minutes ago. The supplier, reached through its established contact, says the destination is not theirs. The requester has stopped responding. You do not yet know whether the receiving account has been credited.

What is the strongest immediate response?

  • Wait for conclusive proof that the money has been withdrawn.
  • Contact the bank through a known channel now, alert the incident owner and preserve the records.
  • Ask the requester to send the money back before involving the bank.
  • Delete the messages and reset every system before reporting.

Recommended response for this scenario

Contact the bank through a known channel now, alert the incident owner and preserve the records.

Ask the bank promptly about available recall or fraud-response action. Notify the incident owner and provide the transaction reference and timeline. Preserve relevant records and prevent further disputed payments through the approved response process. Recovery is uncertain, even when action is quick.

Why each choice matters

Wait for conclusive proof that the money has been withdrawn.
Waiting for that fact can reduce response options.
Contact the bank through a known channel now, alert the incident owner and preserve the records.
This starts time-sensitive bank action while the organisation investigates and contains further exposure.
Ask the requester to send the money back before involving the bank.
That relies on a disputed actor and delays independent action.
Delete the messages and reset every system before reporting.
Deleting records can destroy evidence. Containment should be coordinated with the incident owner.

Practical control: Keep a known bank escalation route, incident owner and evidence checklist accessible to the payment team.

Discuss: What information can you supply immediately without delaying bank contact?

Case 05

The urgent request turns out to be real

Independent checks confirm the supplier change. Both authorised approvals are recorded. The amount, purpose and due time match the order, and no unresolved discrepancy remains. A team member still wants to delay for several days because the first message sounded suspicious.

What is the most proportionate next action?

  • Delay every unusual request for several days regardless of completed verification.
  • Release this payment and remove future verification for the supplier.
  • Release through the approved process and retain the verification record.
  • Require a voice-detector result even though the transaction is independently verified.

Recommended response for this scenario

Release through the approved process and retain the verification record.

The evidence and approvals support release. Good verification should lead to a clear decision, including proceeding when the conditions are satisfied. Retain the record and apply the same change process to future requests.

Why each choice matters

Delay every unusual request for several days regardless of completed verification.
An arbitrary delay adds friction without addressing a remaining identified uncertainty.
Release this payment and remove future verification for the supplier.
One verified event does not establish all future changes.
Release through the approved process and retain the verification record.
The required conditions are satisfied. Useful controls allow legitimate transactions to proceed.
Require a voice-detector result even though the transaction is independently verified.
The detector is not the unresolved decision need in this case.

Practical control: Define a release condition as clearly as a hold condition. Track avoidable verification delays as well as exceptions.

Discuss: Which remaining uncertainty would justify a further hold?

Case 06

Two checks share the same weakness

A review finds that two approvers routinely confirm changed bank details by replying to the same email thread. No fraud has been reported. The process document lists this as independent verification because two employees participate.

What improvement should the owner prioritise?

  • Make the verification route independent and rehearse a fictional change with both approvers.
  • Add a third approver who reads the same thread.
  • Keep the process because no loss has been reported.
  • Send a general deepfake-awareness video and leave the workflow unchanged.

Recommended response for this scenario

Make the verification route independent and rehearse a fictional change with both approvers.

Separate approval authority from the source of verification evidence. Two approvals can still share one compromised information path. Rehearse the revised route, including an unavailable contact and a bank cutoff, then fix the practical gaps observed.

Why each choice matters

Make the verification route independent and rehearse a fictional change with both approvers.
This addresses the shared evidence weakness and checks whether the process works in practice.
Add a third approver who reads the same thread.
Another approver does not repair the shared dependency.
Keep the process because no loss has been reported.
Absence of a reported incident does not establish that the verification route is sound.
Send a general deepfake-awareness video and leave the workflow unchanged.
Awareness does not by itself establish a reliable transaction-verification path.

Practical control: Document the independent route, its owner, approved alternatives and how exceptions are recorded.

Discuss: What would a short rehearsal need to demonstrate before the revised process is usable?

Worked example / Fictional teaching context

Payment instruction and escalation card

Illustrative assumptions, not a customer result, forecast or professional assessment. Keep the conditions beside the numbers.

Request
Fictional AED 84,000 supplier payment to changed bank details
Evidence gap
Existing invoice is valid; changed destination is unverified
Verification
Use the previously established supplier contact, independently of the new message
Approval
Apply the organisation’s existing beneficiary-change and transaction approvals
Decision
Hold the changed destination pending verification; preserve a legitimate approved route if available
If already sent
Contact the bank through a known channel immediately and involve the incident owner
Evidence
Record transaction identifiers, relevant messages and the response timeline without altering originals

Try the idea in a different situation

An urgent payroll message changes an employee’s account. Explain what carries over from the supplier example and what must follow payroll policy.

Prompts for your discussion
  • Uses an independently established identity and request-verification route.
  • Preserves the relevant payroll authority and approvals.
  • Defines prompt escalation if a change or transfer already occurred.

Use these prompts to examine the reasoning, not to award a score or certify readiness.

Sources and limits

Keep the context with the decision.

Original fictional educational cases. All companies, prices, volumes and outcomes are illustrative. Sources support the stated principles, not claimed customer results. Completion is a learning record, not a professional assessment.

Editorial source review: 2026-09-17. Not legal approval or a verified readiness assessment.

  • All scenario facts and numerical examples are fictional. They are not verified customer results or estimates of a particular business’s performance.
  • The stated durations are planning estimates. Learning outcomes and commercial impact have not been validated with intended readers.
  • Source guidance is used for the stated principles. It does not establish legal applicability, certification or professional approval.
  • Changed-fact prompts support discussion. This is a fixed case sequence, not a branching simulation.

/ CITE OR SHARE THIS GUIDE

Make the evidence easy to verify.

When you reference this guide, link to its canonical URL. That gives readers one stable place for the evidence, limitations and future updates.

Suggested citation

dotSuper Research Desk. (September 17, 2026). The CEO called. Would you approve the payment?. dotSuper. https://dotsuper.net/feeds/applied-systems/payment-verification-decision-lab

Share on LinkedIn

Move from practice to your operating context

Put the decision into practice

Walk through one fictional beneficiary-change request using the organisation’s current roles and trusted contacts.

Talk with dotSuper