How One Lithuanian Turned Google and Facebook Into His Personal ATM for Two Years – and Why Your AP Team Could Be Next
No server breach. No malware. Just emails, letterheads, and a carefully chosen company name.
Over two years, two of the world’s largest tech corporations wired away $122 million – and every transfer looked entirely legitimate to their own finance systems.
Anatomy of the scheme
Lithuanian national Evaldas Rimasauskas didn’t breach Google’s or Facebook’s IT perimeter. He walked around it.
Step 1. He registered a company in Latvia called Quanta Computer – an exact namesake of the real Taiwanese hardware manufacturer both corporations already did business with.
Step 2. From 2013 to 2015, AP staff at both companies received targeted phishing emails from “managers” at their familiar supplier, complete with forged invoices, contracts, and company seals.
Step 3. The real trigger was a notice about changed banking details. That single step was enough: the money moved to accounts in Latvia, Cyprus, Hungary, and Hong Kong.
The outcome. Google wired roughly $23 million; Facebook, roughly $99 million. It took internal audit teams and the FBI until 2015-2017 to unravel the scheme. Rimasauskas was arrested in Lithuania and extradited to the US in 2017, and in 2019 he was sentenced to 5 years in prison along with forfeiture of nearly $50 million.
Why standard controls didn’t stop it
This wasn’t a story about careless employees. It was a story about process architecture.
- Vendor verification was a one-time event. A new or lookalike vendor passed checks once – and the system trusted it from then on.
- Bank detail changes were accepted on faith. A letter with a seal isn’t proof of identity – it’s just text.
- There was no purchase order matching. Large invoices weren’t checked against an actual PO; they were approved out of habit.
- Communication channels were never reconciled into one picture. Different emails, to different people, at different times – no one ever saw the full scheme at once.
If bank details in your company can change on the strength of an email from a “familiar” vendor, and invoice approval still runs on manual back-and-forth rather than systematic checks – you’re sitting in the exact same risk zone Google was in back in 2013.
How this gets closed architecturally – the D365 Invoice Capture example
Microsoft Dynamics 365 Invoice Capture, paired with Power Platform, turns invoice review from manual paper-reading into automated exception-based control.
- Fuzzy vendor matching. The system flags lookalikes such as “Quanta Computer, registered in Latvia” as early as document recognition – by name, tax ID, and legal address, not just text similarity.
- Centralized channel management. Every incoming invoice – from email, a shared mailbox, SharePoint, or OneDrive – lands not in scattered individual inboxes, but in one configurable intake channel. Each file is logged with its sender and automatically tied to the correct legal entity and access level. This directly closes the gap Rimasauskas’ scheme exploited: sending invoices through different channels and different people to fragment the picture no longer works, because everything converges into a single traceable stream.
- Three-way matching. Invoices are checked line by line against the purchase order and the goods receipt. No real PO, no automatic payment – no matter how convincing the seals look.
- Org structure driven by Entra ID. Invoice approval routing runs off the live hierarchy in Entra ID, not a static list of approvers. If the person who was supposed to sign off has left, been promoted, or has a different authority limit, the system automatically escalates up the chain – instead of getting stuck on an outdated route or routing “from memory” to the wrong person.
Legitimate invoices flow through automatically. Any deviation – an unfamiliar bank, a missing PO, mismatched details – halts the process and requires sign-off at the security level, not just from an AP clerk.
What to ask your team today
Three questions for your CFO, CISO, and head of AP:
- Can a vendor’s bank details change on the strength of an email alone?
- Is every large invoice checked against a real PO, or do some payments still move on trust?
- Does your invoice approval system know who actually holds sign-off authority today – or has the approver list gone stale since your last reorg?
If you’re not confident in the answer to even one of these – you don’t have a people problem.
You have an architecture problem.