What is the point in having arbitrary username requirements?
There are two main arguments for enforcing requirements/restrictions on username choices. The first is that making usernames more difficult for attackers to predict helps resist online guessing attacks. While usernames aren't necessarily considered to be as secret as passwords they are one of at least two pieces of information that must be stolen to impersonate a user. We shouldn't dismiss the advantage of this information remaining unknown to attackers.
The 2007 paper Do Strong Web Passwords Accomplish Anything? (PDF) evaluates the threat of online password guessing and considers the what our options are to combat it. A site can enforce a stricter password policy which may hurt usability if users struggle to comply and experience frustration with the process. Or the site can enforce some username restrictions and keep the password policy the same. Their theory being that if an attacker has to try a lot of possible combinations it doesn't matter as much whether that's due to easy usernames and complicated passwords, or semi-complicated usernames and semi-complicated passwords.
This ignores a third option of the site adding a second authentication factor to supplement the security of a password while leaving usernames alone. It also requires the site to work harder to avoid disclosing valid usernames that attackers can then pair up with possible passwords.
The second argument is that by enforcing somewhat unique username requirements a site can hope to deter users from choosing the same credentials they've used on other sites. This is a very real threat and it's a difficult one for a site to do anything about besides enforcing unusual usernames requirements (or assigning IDs themselves). However, one awesome study from 2010 monitored actual username and password reuse by people between their banks and other sites. The study found that people did indeed reuse their bank password on other sites 73% of the time, but also found that even if a bank enforced unique username conventions people would then reuse that username on at least one other site 42% of the time.
So enforcing unique username requirements lowered the chances of credential sharing, but certainly didn't eliminate that possibility. But that lower risk may still be seen by some sites as worth the inconvenience to users.
Another possible reason, that's less of an argument and more of a requirement, is legacy system compatibility. Whatever potentially old software is doing back end processing behind the snazzy web front end may have been coded to only accept usernames formatted a certain way. Without ripping out and replacing that software the site may be stuck passing on the restriction to customers. The 'User IDs cannot begin with an X' line leads me to believe this may be a factor in your case.
These user names requirement can cause user names to be less predictable. I don't think that this provides a substantial security improvement, but I can think of a couple of scenarios where they help a little. I doubt that it offsets the loss of usability, but I lack concrete evidence to conclude. As usual, security at the expense of usability, comes at the expense of security.: if users are more likely to forget their usernames, this means that either they'll have to store their username in an insecure location (defeating the purpose) or there has to be a way for them to recover their username (which may not be strongly authenticated).
Less-predictable user names improve privacy. If I try to create a johnsmith account and it fails because that username is already in use, this tells me that John Smith is banking with that firm. If John Smith's account is johnsmith1, I need to enumerate more usernames. However, with user-chosen usernames, the suffix 1 is a very good bet. Most websites rely on email addresses as unique tokens — if I want to create an account as [email protected], I'll need prove that I can read email sent to this address. Banks are usually reluctant to depend on external security, so they tend not to want to depend on email providers.
A significant number of attacks on banking are performed in a home setting — a spouse, a child, a visitor, etc. A less-predictable username can improve confidentiality against a casual attacker who has access to the victim's computer but is more likely to perform opportunistic attacks than to seriously research their attack. Again, with a user-chosen username, the complexity requirement isn't a significant improvement: many users will leave their username pre-filled in their browser, and if they don't choose johnsmith1, the variation is likely to be known to the attacker since they know each other well.
Less-predictable usernames also improve the defense against non-targeted attacks that work by trying out a lot of username+password combinations until a weak one is found. Again, having to try johnsmith1 in addition to johnsmith doesn't provide a significant improvement.
As for user IDs not beginning with X… it's a bank. Deep inside the bowels somewhere is a COBOL program running on an emulated IBM big iron running on a slightly more recent emulated IBM big iron running on an emulated VAX running in a virtual machine on an x86 processor. Before you were born, someone decided it would be a good idea to indicate deleted records by putting an X in the 17th column. The COBOL programmer who was brought out of requirement to fix the Y2K bug offered to fix that as well, but was told that this was outside the job spec and he was not to touch something that works (this could have worked out differently if the bank director's name had been Xavier instead of George).
- To make user IDs less predictable.
- To conform to other systems.
The reasons for less predictable user IDs might be:
An application limits a number of password guesses (a typical thing for internet banking) per a user ID. Then an attacker can mount an attack "try password 123456 for all known user IDs". If the attacker does not know the large amount of user IDs, this attack does not make much sense.
An application might have some design security flaws which we do not know. For example, an application might use a user ID to derive a session token.
'X' as the first letter might be disallowed to prevent interpreting a user ID by some (legacy) system as a hexadecimal number.