What should merchants do when staff or host accounts are part of the fraud path?

What merchants should do first when staff or host accounts appear in the fraud path

Merchants should treat the account itself as part of the attack surface, not just the transaction or booking event. That means identifying which people and operational roles can reach booking tools, OTA messaging systems, guest profiles, refunds, overrides and other privileged hotel workflows, then reducing access to the minimum needed for the job.

When fraud paths involve staff or host accounts, the core question is whether those accounts can be abused, borrowed, or stolen to make fraudulent activity look legitimate. If the answer is yes, the control problem is not only fraud detection, it is also access governance, credential handling and fast removal of standing access that should not persist outside the business need.

How to think about staff and host accounts as fraud enablers

Staff and host accounts often sit close to trusted business functions, which makes them attractive for misuse. A compromised account can be used to alter reservations, reroute messages, issue refunds, change guest details or suppress warning signs that would otherwise be visible in customer-facing channels. That is why these accounts deserve the same scrutiny merchants apply to payment or admin paths.

The practical issue is that fraud teams and operations teams may each see only part of the problem. Fraud analysts may spot suspicious outcomes, while hotel or merchant operations own the tools and workflows that made those outcomes possible. If access is broad, shared, or difficult to attribute, it becomes harder to tell whether an act was an insider misuse, a stolen login, or a process failure.

A useful mindset is to map the account to the action it can perform, then ask whether that action can create financial loss, guest deception, or message tampering without an obvious break in the workflow. If it can, the account is not just a user record, it is a control point that needs tighter authority boundaries and better visibility.

What merchants need to tighten in access, monitoring and revocation

Merchants should start by reviewing who can access booking platforms, OTA inboxes, PMS functions, refunds, escalation channels and any privileged hotel workflow that can change money, inventory or customer communications. That review should include dormant accounts, shared logins, agency access, seasonal workers and any role that still has access after job changes.

Access should be limited to the smallest workable set of privileges, with stronger review where the workflow can create irreversible impact. Suspicious access should be revocable quickly, especially if the account can reach customer communications or payment-adjacent actions. The faster the organization can cut off access, the smaller the fraud window becomes.

Monitoring needs to focus on abnormal use of trusted tools, not just failed logins. Unusual after-hours activity, bulk message sends, atypical refund timing, changes to booking details outside normal job patterns, and repeated access from new devices or unfamiliar locations are all signals that the account may be part of the fraud path. For account-focused fraud review, Identity Fraud Prevention Guide is a useful reference for linking access anomalies to abuse patterns.

Lifecycle governance matters as much as detection. If an employee leaves, changes role, or no longer needs privileged workflow access, that access should be removed promptly and verified after the change. Strong onboarding is not enough if offboarding and role change processes leave old permissions active for days or weeks.

Why fraud response fails when account governance is weak

Fraud programmes often focus on the suspicious event, but the account may be the real compromise point. If staff credentials are reused, shared, long-lived or poorly protected, one compromised login can expose multiple tools and workflows. That creates a broader blast radius than a single fraudulent transaction and can let the attacker operate inside normal business processes.

Weak governance also makes investigations slower. If several people use the same host account, or if a partner or contractor still has access after the work ended, it becomes difficult to establish who did what and when. That slows containment, complicates root-cause analysis, and can allow further misuse while the team is still sorting attribution.

For merchants that depend on hotel operations or OTA channels, the lesson is simple: account controls are part of fraud control. The more a workflow can move money, alter trust, or impersonate legitimate communication, the more important it is to know exactly who can reach it and how quickly that access can be removed. When access is part of the fraud path, PCI DSS v4.0 is a relevant benchmark for restricting access by business need and governing system account use.

Practitioner Guidance

What to prioritise: Start with the accounts that can change bookings, refunds, guest communications or other privileged hotel workflows. Those are the accounts most likely to create direct fraud impact if misused.

What to verify: Confirm that every staff, host, contractor and agency account has an owner, a current business justification, and a clear removal trigger for role change, inactivity or exit. Shared or unowned access should be treated as an exception, not a normal operating model.

What good looks like: The organization can show who has access, why they have it, what they can do, and how quickly that access can be revoked when it looks suspicious. Fraud monitoring and access governance should reinforce each other, not operate as separate silos.

Practitioner takeaway: If staff or host accounts can participate in fraud, treat them as high-value control points, because reducing privilege and shortening revocation time often prevents more loss than trying to detect every fraudulent action after the fact.

Related resources from NHI Mgmt Group

• Why do non-human identities create more audit risk than human accounts?
• How should security teams govern non-human identities alongside human accounts?
• What problem does ownership attribution solve for service accounts and API keys?
• When do service accounts become a higher risk than ordinary user accounts?