Not only does the credit bureau max out their password length, you have a small list of available non-alphanumeric characters you can use, and no spaces. Also you cannot used a plused email address, and it had an issue with my self hosted email alias, forcing me to use my gmail address.
Both Experian and transunion had no password length limitations, nor did they require my username be my email address.
Update: I have been unable to log into my account for the last 3 days now. Every time I try I get a page saying to call customer service. After a total of 2 hours on hold I finally found the issue, you cannot connect to Equifax using a VPN. In addition there is no option for 2FA (not even email or sms) and they will hang up on you if you push the issue of their security being lax. Their reasoning for lax security and no vpn usage is "well all of our other customers are okay with this".
There may also be a (very weak) reason around bounds checking and avoiding buffer overflows. By rejecting anything longer that 20 characters, the developer can be sure that there will be nothing longer sent to the back end code. While they should still be doing bounds checking in the rest of the code, if the team making the UI is not the same as the team making the back end code, the UI team may see it as a reasonable restriction to prevent a screw up, further down the stack, from being exploited. Again, it's a very weak argument, but I can see such an argument being made in a large organization with lots of teams who don't talk to each other. Or worse yet, different contractors standing up the front end and back end.
They really shouldn't be sending the password over the line at all. It should be local hashed/salted, encrypted, and then sent. So plaintext length really shouldn't matter much, if at all. But I see your point.