Operators can now ban a customer from their profile without deactivating the account first, and lift a ban just as easily. Every ban and unban is recorded against the customer with who did it, when, and why, giving you a clear audit trail for compliance.
Why this matters
Previously, banning a customer meant either adding a row to the Banned Customers table (which didn't record the action against the customer's own account) or deactivating the account and banning at the same time - which meant clearing tickets, subscriptions and balance before you could act. Neither option let you move quickly or show a regulator exactly what happened. Banning is now a stand-alone action that works the same way as self-exclusion: you can apply it at any time, and the record lives on the customer's profile.
What's new
Ban a customer in one step
From a customer's profile in Admin, click Ban account, choose a reason from the dropdown (select Other to add free text), and confirm. The platform then takes the same protective actions it does for self-exclusion:
- Logs the customer out of all active sessions and blocks sign-in
- Cancels open tickets, syndicate shares, autoplay, subscriptions and scheduled purchases
- Turns off marketing communications
- Downgrades membership programs, deactivates trusted devices and unlinks social logins
The account itself stays active, so you're no longer blocked by deactivation prerequisites such as a zero balance.
Banned status is clearly visible
A banned customer now carries a clear label on their profile, in the same way self-excluded and locked accounts do, so anyone handling the account knows its status at a glance.
Full audit trail on every ban and unban
Each action records the reason, the operator or system that triggered it, and the date and time. A CUSTOMER_BANNED event is logged when a ban is applied, and a new CUSTOMER_UNBANNED event when it's lifted. If a ban is applied automatically (for example, a new signup matching an existing banned record), that's captured too.
Lifting a ban requires a separate permission
Removing a ban is a controlled action. Operators need the new customer_ban.remove permission to click Remove ban on a profile and record the reason. This lets you show regulators that there's a distinct control around who can reverse a ban.
Phone number added to banned customer matching
Banned customer records can now include a phone number. When a new account is created or a customer signs in, the platform matches on name and date of birth and either postcode or phone number. This makes it harder for a banned customer to get around the check by changing a single detail. Phone numbers are stored in a consistent format and only valid numbers are used for matching, so an invalid or incomplete number won't cause a false match.
The phone number field is also available when adding or editing records in the Banned Customers table, and in the bulk import.
Export the banned customers list
You can export the banned customers list from Admin for audit and regulatory reporting.
Note: Existing banned customer records keep working exactly as they do today. Records without a phone number still match on name, date of birth and postcode.
Who this impacts
This applies to all JLP partners. The most immediate benefit is for fraud, compliance and support teams who manage banned customers - particularly operators who need to demonstrate controls and produce audit records for a regulator.
Admin setup
No feature switch is required - the change is live for all partners on release. To use it, operators need the following permissions:
- Customer edit - ban a customer from their profile page
- Customer ban remove (
customer_ban.remove) - lift a ban from a customer's profile - Ban edit - add or edit entries in the Banned Customers table
Manage banned customer records at Admin > Operations > Fraud tools > Banned customers.
Note: The add_to_ban and remove_from_ban options have been removed from the account deactivation flow. Banning and deactivation are now separate actions.