A dealership can remain open, its phones can keep ringing, and its sales software can appear healthy while customer trust is being undermined somewhere else. When transaction details are stolen from a technology provider, a convincing payment request can be assembled without the dealership's own network being shut down. For dealer principals, that distinction deserves attention: an operational dashboard may show green while a buyer is being persuaded to send a vehicle deposit or final balance to the wrong account.
That risk was illustrated by October reporting on the GeNesys dealer software breach in Germany. Order details, delivery dates, and financing amounts were reportedly exposed, creating material that could be used in payment-redirection scams. Police had not identified fraud attempts in the account cited by that report, so potential harm should not be confused with confirmed losses. Nevertheless, the lesson travels well beyond Germany: knowledge of a customer's purchase is no longer reliable proof that a message came from the dealership.
Accurate Deal Details Are Not Authentication
A buyer who receives an email naming the correct salesperson, vehicle, balance, and delivery date has several reasons to believe it. Those familiar details are normally treated as reassurance, particularly when delivery is approaching and paperwork is being completed quickly. If that information has been copied from a vendor's system, however, each reassuring detail can be reproduced by someone with no authority to collect payment. The point of failure is then not simply a suspicious attachment or a weak password; it is a payment process that allows familiarity to substitute for verification.
In my view, the most useful question for dealership leadership is not whether employees would recognize a badly written scam, but whether a well-written request would be stopped by the process. Our earlier review of dealership cybersecurity risks before year-end considered vendor exposure and remote access. This narrower issue deserves its own discussion because protecting the showroom's systems and protecting the buyer's next payment are related responsibilities, but they are not identical.
Build Verification Into the Customer Journey
Payment instructions should be established through a trusted channel early in the transaction, with customers told how any later questions will be handled. A request to change banking details should trigger a pause and independent verification using a telephone number already recorded on the purchase agreement, rather than one supplied in the new message. Within the dealership, changes should be approved by a second authorized person and documented. These controls cannot guarantee that fraud will be prevented, but reliance on a single email exchange can be substantially reduced.
The same discipline should be applied to technology providers. Responsibility for notifying the dealership of a suspected compromise should be clarified, along with the information that would be supplied and the people authorized to coordinate customer communications. A tabletop exercise can then be run around a realistic scenario: deal information has been exposed, the DMS remains available, and buyers may receive false payment requests. Unlike a conventional outage exercise, success is measured by how quickly a consistent warning can be delivered and a questionable transaction can be escalated.
At ComSolutions, I would treat that rehearsal as a practical extension of business continuity, not an exercise in assigning blame. Our discussion of disaster recovery testing makes a similar distinction between a written plan and a demonstrated capability. For dealerships, the next step is to bring finance, sales, management, and IT into the same conversation. A modest verification delay is easier to explain than a lost payment, and a trusted customer relationship is worth protecting before delivery day arrives.
