Suspicious Bookings: A Pre-Arrival Red-Flag List

Most bad bookings announce themselves before arrival, in the way they ask rather than in what they pay. The list is short and the order matters.

Last updated: October 28, 2026

A bad booking rarely looks like a bad booking. It looks like money arriving early, which is why hosts talk themselves out of the feeling. The useful move is to stop asking whether the guest seems trustworthy and start reading the request itself: what they ask for, what they won't answer, and who is paying.

Key Takeaways

• The flags are behavioural, not personal. What someone asks for and how they answer belongs on the list. Who they are doesn't, and never did.
• One plain question does most of the work. Who's staying, and will the person paying be there at check-in. How it's answered tells you more than what's answered.
• Match the name on the payment to the name on the booking. When those two don't line up, ask why before you ask anything else.
• A refusal belongs in the thread. Short, on the platform, naming the condition that wasn't met rather than the suspicion you had.
• The platform is a record, not a screening service. It holds the thread and reviews cases. It can't see what you noticed.

The flags that come before arrival

Start with the ones that are hard to argue with, because they're about the transaction rather than the person.

Someone wants payment or a deposit moved off the platform, or offers a discount for paying directly. Someone asks for the door code, the key location or the exact unit number before the booking is confirmed. Someone pays from an account in a name that isn't the name on the booking, and the explanation changes the second time you ask. Someone books for two and mentions four more in a message the night before. Someone wants to check in but won't be the person staying, and can't or won't name who will be.

Then the softer set, which is about shape rather than content. Answers that arrive fast but don't address the question. A thread that reads like a script, repeating the same sentence in different words. Urgency that doesn't match the calendar — a booking for next month, needed confirmed in the next ten minutes. A guest who negotiates hard on price and then stops caring about it entirely.

None of these is proof of anything. Each of them is a reason to ask one more question, which is a much lower bar and a much more useful one.

What doesn't belong on the list is worth saying plainly: nationality, age, gender, the language a message is written in, the sound of someone's name on a call. None of those is a fact about this booking. All of them are facts about the person, and treating them as risk is both wrong and, in most places, unlawful. If a flag can't be written as "they asked for X" or "they wouldn't answer Y", it isn't a flag.

Ask, verify, decline

Three steps, in that order, and most situations stop at the first one.

Ask. One plain question, in the thread: who will be staying, and will the person paying be at check-in? Keep it ordinary. You're not conducting an interview, and a normal guest answers a normal question without noticing it. What you're reading is the shape of the reply — a name and a date, or three sentences that don't contain either.

Verify. Two things, and only two. The name on the payment against the name on the booking, and the guest count against the occupancy you can legally and practically host. Anything beyond that is the platform's job, published in its own terms. If the payment name belongs to a company or a relative, that's fine — ask which, and write the answer down.

Decline. If the answers don't come, or the story keeps moving, refuse. Do it in the thread, on the platform, in three sentences: what was asked for, what wasn't provided, and which condition of the booking it fails. That's usually occupancy, the payment method the listing accepts, or the rule that the person staying has to be contactable. Don't accuse. Don't explain your instinct. An accusation you can't evidence is the one thing that turns a clean refusal into a complaint.

The comparison is only as good as what you can see next to it. localsbnb.com shows a booking's dates, guest count and the channel it came in on in one view, so the name on the payment has something to be checked against. On an overseas property, a check-in, a check-out, an extension or a room move each need a person to confirm, so nothing about the stay moves while you're still deciding.

The order matters because each step produces a record the next step can lean on. Skipping to the refusal leaves you with a decision and no reason, which is the version that gets reversed.

What the platform will and will not do

The platform holds the booking, the thread, the name on the payment and its own verification state. That's a real amount of information, and it's the reason to keep everything inside the thread rather than on the phone.

What it won't do is tell you that a guest is a problem before they arrive. Verification steps confirm what they confirm; they don't clear a booking, and a passed check isn't a promise about the stay. Each platform publishes what its process covers and what it leaves to the host, as published and subject to change. Read that page once a year; it's shorter than you'd expect and it's the only version that counts.

The practical consequence is that the decision stays with you. The platform can review a cancellation afterwards, and it will read the thread. It can't see the thing that made you uneasy at nine in the evening.

This is also where the record is cheapest to keep. Two names and a guest count are already in the thread, and nothing extra has to be collected now to answer the question in a month.

Documenting a refusal

A refusal is a piece of writing, and it should read like one a month later, to someone who wasn't there.

Write it in the thread. Include the date and the time of your question, the question itself, how long you waited, and what came back. Then the decision, in one sentence, with the condition named. "The booking is for two guests, and four more were added for the same night; the listing sleeps two, so I can't accept the stay as it stands." That's a refusal someone can read without needing your tone of voice.

Save the whole thread, not a screenshot of the part that supports you. Save the payment name as it appeared. If a call happened, write a line in the thread afterwards saying what was discussed — a record you create yourself, at the time, beats a recollection you offer later.

Then leave it alone. If the guest replies angrily, don't match the temperature. One more factual line, then silence, then let the platform process do what it does. Editing the thread to look better is the one move that turns a defensible refusal into a questionable one.

And when a booking turns out fine after a second look, say so in the record too. The list is a way of asking better questions, not a way of building a file on people. A host who logs every outcome, including the ones that went nowhere, is the one whose judgement stays calibrated.

FAQ

Isn't a red-flag list just profiling with extra steps?

It is if the list is about people. It isn't if every line can be written as something the guest did or refused to do. Test each item that way: if it can't be said as "they asked for X" or "they wouldn't answer Y", it comes off the list. That test also happens to keep you on the right side of discrimination rules, which isn't a coincidence.

Can I just cancel and sort it out afterwards?

You can, and it costs you. A cancellation outside the terms you published is a decision the platform will review, and the thread is what it will read. Declining with a named condition is slower by ten minutes and much easier to defend than a cancellation with no explanation attached.

What if the platform's verification has already passed?

Treat it as one signal among several, not as clearance. Verification confirms what it was built to confirm, and every platform publishes the limits of that. It doesn't know that four extra guests arrived in a message at eleven at night, or that the payment name belongs to someone who isn't coming.

The list is short on purpose: a handful of behaviours, one question, one comparison, one written refusal. None of it requires you to judge a person, which is the point — you're judging a request, and the request either answers or it doesn't. localsbnb.com puts every connected channel's bookings on one calendar, so the request you're weighing sits next to the week it belongs to.

---

This article is general guidance for hosts and isn't legal, tax or insurance advice, and it isn't a screening standard. What a host may ask, refuse or record is set by local law and by each platform's current terms, and both differ by place. Confirm the current rules with the competent authority and the terms of the platform you use before you change how you accept bookings.