After an invoicing incident: who can change where a payment goes?
Knowing an invoice does not establish authority to change its receiving account. Review how a request is confirmed, approved and executed.
Читати португальськоюBy Pentesty
The updated statement changes the news context
In its October 1, 2026 update, Fakturownia confirmed data copying through unauthorized access and said the incident involves all accounts, with differences by category and period. In a September 30 statement, Poland’s finance ministry said it had not identified a KSeF compromise. The analysis below proposes a business exercise; it does not describe confirmed payment fraud in this incident.
Test a change from start to finish with fictional data
Use a test supplier and obligation in an authorized environment. Agree on the expected result before starting. Follow the request through to a simulated payment instruction, preserving the separation between the person editing information and the person accepting the change.
- Request: record the channel, claimed identity and intended change without treating those elements as confirmation.
- Verification: confirm through the previously registered contact and record who checked it. A number supplied in the request itself does not meet this criterion.
- Approval: check whether an account lacking the required role can complete the change. Record the expected denial and any authorized exception.
- Execution: compare the approved beneficiary with the destination in the simulated instruction. Check whether later changes require a fresh decision.
Include integrations and work already pending
A change may cross a finance application, supplier directory and external service. Identify which system determines the destination and which integrations can modify it. Rotating a credential requires observing effective permissions afterward, including scheduled jobs. An updated screen does not demonstrate that an older queue has stopped using previous information.
This connects with third-party query and access boundaries. The exercise hypothesis should include an allowed operation and an out-of-scope attempt. Observe the outcome in the component receiving the operation, without using customer information or samples attributed to a data leak.
Deliver a decision about the observed workflow
Record system versions, test accounts, the requested change, expected approval and observed result. The finance owner should understand what needs changing; the technical team should have enough evidence to repeat the check. Also define how to handle requests pending during remediation.
Pentesty’s analysis is that acceptance needs to connect records, authorization and execution. A pentest can assess digital controls within scope, while the company remains responsible for commercial confirmations and financial decisions. Repeat the scenario after changing an integration or procedure, also checking that legitimate payments remain possible.
Arkéa: reconcile the work left on hold
Editorial update: November 5, 2026
In clarifications dated November 4, 2026, Crédit Mutuel Arkéa said attackers went through a provider’s platform and used the bank’s own account to carry out transactions. The institution denied entry through Fortuneo and reported temporarily suspending certain operations. This is a separate case from the Fakturownia incident discussed above.
In its initial statement, the bank said customers’ assets were unaffected, although some transfers were delayed. In the subsequent clarifications, it did not confirm the exact publicly reported amount: it validated only its order of magnitude and said some funds had been blocked. A final net loss remained under assessment.
For Pentesty, recovery adds a question to the exercise: how do you distinguish an instruction on hold from one already executed? In an authorized environment, use fictitious instructions with unique identifiers. Simulate an integration interruption between approval and confirmation, record each system’s states and have the finance owner reconcile pending work and outcomes before release.
In the retest, resubmit the same simulated instruction and check the agreed behavior for preventing duplicate execution. Also check whether an integration account can change a beneficiary or release an instruction beyond its approved scope. Retain the decision, receiving-system records and operational confirmation. These are proposed assessment criteria that move no real money; they do not describe Arkéa’s existing controls or establish that they would have prevented its incident.
Confidentiality does not authorize skipping verification
Editorial update: November 10, 2026
The DOJ’s November 5, 2026 release, updated November 6, describes fraud allegations covering 2024 through 2026. According to the allegations, participants impersonated executives’ voices or images, then posed as attorneys to induce transfers exceeding $129 million. These are allegations, without a finding of guilt; the release does not demonstrate a particular model’s technical capability.
This context adds a hypothesis to payment testing: can someone who appears to be an executive authorize skipping normal verification? Introducing a second caller as an attorney does not create independence when both contacts came from the same request. IC3 recommends secondary channels to verify bank-account change requests. Defining who may approve exceptions remains the organization’s decision.
In an authorized exercise that moves no money, use a fictional request claiming urgency or confidentiality. Check whether it still requires the prescribed confirmation through a previously validated contact and approval scoped to that instruction. Record who can substitute for an unavailable approver as well. A new contact provided by the requester does not meet the proposed independence criterion.
Retain the request, applied rule, decision and simulated payment destination. Compare a legitimate case with one attempting to skip review, observing the outcome in the component receiving the payment instruction. This is an editorial assessment criterion, not a description of controls at the companies mentioned in the allegations. If actual fraud is recognized, contact the responsible teams and financial institution promptly; requesting recovery does not guarantee returned funds.
Frequently asked questions
Does an invoicing incident establish payment fraud?
No. This article uses the statement as context for an exercise. A conclusion about fraud requires evidence of the request, authorization and execution of the particular payment.
Does a correct invoice number confirm the requester’s identity?
It identifies a bill but does not establish authority to modify the beneficiary. Use the approved procedure and a confirmation contact established before the request arrived.
Does changing an integration key complete the review?
Check permissions, pending jobs and the result in the receiving system. Replacing a credential needs to preserve authorized work and remove access that is no longer necessary.
What evidence should we request during a retest?
Request repetition of the change using fictional information, the approval decision and the destination of the simulated instruction. Record limitations and confirm legitimate operation with the finance owner.
Sources and references
Original Pentesty analysis, published October 16, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.