A False Wire Instruction Tests Family Office Cybersecurity

A family office can have encrypted files, multifactor authentication and an outside IT provider—and still send money to an impostor. The failure may occur in the space between those protections: a familiar email arrives with new bank details, the person who knows the vendor is away, and the person authorized to release the wire assumes someone else checked the change.

Family office cybersecurity is the control of those handoffs as well as the protection of systems. A useful starting test is simple: could a false payment instruction reach bank release, and what evidence would show where it stopped? The same exercise exposes who owns access to family records, outside-provider accounts and incident response.

01Map the Accounts and Records at Risk

The office's exposure reaches beyond its computers. A principal may approve investments from a personal phone. A property manager may send invoices. Counsel and accountants may hold copies of entity records. Family members may receive sensitive documents through accounts the office does not administer. EY's US family-office analysis emphasizes staff and third-party limits.

The office should name the assets whose compromise would change an actual decision: bank and custodian access, payment instructions, legal-entity records, tax and identification documents, private investment files, and the communications channels used to authorize them. A system inventory matters only if it identifies who can read, change, approve or transmit those assets.

1Record Who Can Access Each Asset

Build a short access map for each critical workflow. List the account owner, every administrator, the outside provider with access, the devices used by approvers, and who removes access when a relationship ends. Ask a family member to identify where a purported urgent request would arrive and whom they would call. If the answer is only “reply to the message,” the office has found a practical gap.

The NIST Cybersecurity Framework 2.0 organizes work as Govern, Identify, Protect, Detect, Respond and Recover. It is a useful structure for assigning these jobs, not a claim that every family office must buy six corresponding tools. An office with a managed provider still needs an internal person who owns the outcome and can judge whether the provider's evidence is adequate.

02Map Who Verifies, Approves and Releases a Payment

Follow a real payment type from first request to bank confirmation before writing a policy. For each step, record the current actor, system and evidence. The obligation to pay, the destination account and the authority to release funds are separate questions. An invoice can be genuine while an attached bank change is false. A correct approval amount does not authenticate the destination.

Fill in the names and inspect who can edit and release a wire at the bank. Separate preparation, verification, entity approval and bank release are the illustrative roles here. If policy requires two authorized approvers, identify both and test that bank access enforces their decisions. Two signatures on the same compromised message do not authenticate a payee.

1A Fictional US$480,000 Changed-Bank-Detail Request

Assume a family office owes US$480,000 for a property renovation. The approved vendor invoice and amount are genuine. Two days before the due date, an exercise facilitator injects a mock email into the normal review route. It says the vendor has changed banks and supplies new details. For this exercise, the proposed account is false. The facilitator knows the genuine vendor has made no change; participants do not. No real wire is prepared or sent.

The mock record shows the expected stop. Its roles and amount are illustrative; the family's documents, bank permissions and payment policy determine actual authority and thresholds.

03Test a False Bank-Detail Request Safely

Run the mock only through a safe route that cannot submit a real wire. Observe who notices the change, who confirms whether the vendor authorized the changed destination, and who can stop the instruction. Separately, the COO inspects the production account's current user permissions, payee-change rules, approval invalidation and release controls, with activity logs as corroboration, through an authorized read-only view or bank-confirmed report. A generic demonstration leaves the bank-enforcement gate Unknown.

For the actual bank-enforcement verdict, name the paying entity, live account, user roles, payee-edit route and release route. Retain account-specific current configuration or a bank-confirmed rule. Then seek a bank-sanctioned safe test showing that an unapproved payee edit or release is rejected. A genuine transaction record may corroborate the compliant path; it cannot prove that the bank would block an unauthorized one. Do not send a fraudulent wire to perform this test.

• Pass: Current rules and safely observed enforcement both support the required separation and reapproval.
• Fail: The settings permit a user to bypass the required approval or release separation.
• Unknown: The rule cannot be established or enforcement cannot be safely observed.

For Fail or Unknown, keep the affected changed-destination route restricted. Record the evidence location, reviewer and retest date.

1Authenticate the Request Outside the Message

The test forces a choice between speed and independently confirming that the vendor authorized the change. FBI IC3 describes business email compromise as a scheme that can use compromised business or personal accounts to redirect legitimate funds-transfer requests. A familiar sender name, reply chain or voice does not prove a new destination.

Use a channel authenticated before the change request. Document its source, the caller and respondent, that respondent's authority, the denied or confirmed account details, and any mismatch. If the normal contact is unavailable, use a separately established route or hold the change. Calling the number supplied in the disputed message merely moves the same unverified claim to a phone.

2Require the Right Approval and Recheck Release Details

For a genuine, independently authenticated bank change, the person authorized for the paying entity sees the invoice, amount, payee and exact new bank details as one approval record. A later account edit requires fresh verification and approval. A separate bank releaser checks the submitted fields against that record, and the controller compares bank confirmation with the entity's payment record. For the false mock change, the process ends at the hold; no approval or release is due.

The genuine renovation invoice remains due. After the vendor denies the new destination, confirm through the trusted route that the previously approved account is still valid. Pay that real obligation only through ordinary entity approval and bank release if their controls are established. If the old destination or release route cannot be verified, keep the payment on hold and escalate the due-date consequence. The false-change exercise itself authorizes neither destination.

Ask the bank or payment provider what permissions and logs it actually offers. Can one user create a payee, alter its account and release a wire? Does a change force new approval? Is the confirmation accessible to an independent reviewer? A small office may have only one controller. If that person has unrestricted edit-and-release rights, the principal or COO should hold changed-destination wires through that route, arrange a second authorized bank user or another bank-controlled workflow, and retest. An outside verbal sign-off alone cannot remove unilateral bank access. Record Fail for the separation control, or Unknown when permissions cannot be inspected.

3Stop, Escalate and Preserve the Record When a Gate Fails

A failed verification is a useful result if it stops the instruction. Record the reason for the hold, who is told, who can authorize a new attempt, and what evidence would close the exception. Do not turn “the family wants it paid today” into an undocumented override. If a legitimate deadline is missed, record that operational consequence separately from the cyber-control result.

For an actual office exercise, record Pass for verification and hold only when observed participants reach the trusted vendor contact and retain the callback source, times, hold and notice before approval. Otherwise record Fail for a bypassed control or Unknown for missing evidence. If staff treat the incoming message or its supplied contact as verification, record Fail at verification, even if a later approver catches it. The fictional exhibit's Pass is an example of the required record, not the office's result.

04Test Access to Accounts and Sensitive Records

A family office can block an unauthorized wire and still expose identity documents, private investment records or a principal's communications. The next control tests should be chosen by the value and sensitivity of the asset, not by whether a product dashboard looks complete.

1Identity and Devices

For critical email, banking, cloud storage and remote access, identify who can add users, reset credentials or change recovery methods. Test whether a former employee or adviser loses access on the agreed date. Require the office's chosen multifactor method on critical accounts, and check the provider's administrative and recovery routes as carefully as the ordinary login. A device inventory should include the phones and laptops from which principals actually approve or transmit requests.

The test output is an access list, a dated removal record and a finding for any unknown account or shared credential. The office should ask its security provider what it monitors and what alert reaches a named person after hours. A subscription receipt is not evidence that the alert path works.

2Sensitive Documents and Third-Party Access

Choose one sensitive record—such as a trust document or tax identification file—and trace who can view, download and share it. Check whether an outside provider has more access than its current assignment requires and whether the office can revoke it without losing the underlying record. The separate family-office document-management guide addresses system selection; the cyber question here is whether access and removal are controlled in the deployed setup.

05Respond and Recover If an Account or Payment Is Compromised

In the mock case, the false account is held before release. If a comparable instruction has already reached the bank, use the office's incident card:

1. Incident lead or backup: Contact the bank immediately through a trusted number and ask about hold or recall options; recovery is not guaranteed.
2. Authorized administrator: Contain the suspect email or payment account through a trusted route.
3. Controller: Preserve the request, approval trail, submitted bank details and transaction status. Mark related pending instructions for review.
4. Incident lead: Decide which related releases to suspend and what evidence is needed before reopening them.

Assign that lead and a backup before an incident, together with contact roles for counsel, insurer, security provider and affected institutions. Applicable notification duties and deadlines depend on the facts and jurisdiction and need advice; the office should not rely on a universal timeline from this article.

Before normal payment release resumes, reconfirm destinations, replace compromised credentials and recovery channels, verify the records used for decisions, and rerun the failed control. The incident lead records who accepted that evidence and reopened the route. The NIST framework separates Respond from Recover; an event can be contained while the workflow remains unsafe to resume.

06Run Two Control Exercises in the Next 30 Days

Assign a sponsor who can require participation across the office and a reviewer who did not prepare the test. A practical sequence is: day 1, name the sponsor and payment route; week 1, obtain trusted-contact and bank user-permission and payee-rule records; week 2, run both exercises; week 3, repair failed gates; week 4, retest and record every open exception. Use calendar dates. The authorized sponsor decides whether an Unknown can remain open, with a restriction on the affected route, named owner and next review date; Unknown never becomes a silent Pass.

1Payment-Instruction Exercise

Use Exhibit 01 for a real payment type, keeping the false instruction inside a safe test route. Name the controller, verifier, entity approver, bank releaser and independent reviewer. Record an owner, evidence and verdict for each gate, then assign an open-exception owner and retest date where proof is missing.

2Sensitive-Record Access Exercise

Choose one document repository and a controlled test account that represents a limited-scope provider. Inspect the actual role settings and revocation record for a former provider without attempting to use departed credentials. Pass when observed current permissions match the assignment and revocation is evidenced. Fail if access exceeds it. Unknown when current permissions cannot be inspected; missing historical activity logs are recorded as a separate evidence gap. Name who will restrict access and when the reviewer will retest.

Keep one result row per material gate, linked by an exercise ID: exercise ID · workflow · test date · step owner · observed action · evidence location · Pass/Fail/Unknown · gap owner · retest date. Add one exercise-level acceptance decision that names any restrictions still in force. Carry the open items into the office's broader risk-management register.