There's generally two big reasons I've seen for this pattern: 1. "Single Sign-On"/Multi-Provider support where the email is used as a lookup key for which Prov

There's generally two big reasons I've seen for this pattern: 1. "Single Sign-On"/Multi-Provider support where the email is used as a lookup key for which Provider to use to log in (redirecting to corporate SAML providers or things like that). (Mentioned by most of the other commenters here.) 2. Another "Wish It Were Multi-Factor" process that (mostly American) Banks cooked up to meet regulatory wording at available loopholes rather than address regulatory intent/spirit (real Two-Factor/Multi-Factor support), in this case specifically for phishing protection. That (dumb) idea was that the user in application settings would pick a recognizable "callback" such as a photo of a cute animal and a word they'd notice. Upon entering the username and before entering the password the application would display this "callback" and in theory the user would remember and know better than to enter their password if they saw the wrong "callback" photo/word. In practice I think we all realize that humans do things like username/password login generally by rote muscle memory, aren't likely to stop and "check the cute animal photo" first, and that whatever APIs returned the "callbacks" would be easily scrapable for phishing anyway if the only real input to them was email address (and maybe a rate limit). At least in my experience most of the sites that did this "cute animal wish it were phishing protection" have since dropped the "cute animal" callbacks (because they were silly), but kept the separate username then password flows. It's easy to assume that that's just laziness on their part after they did all that work to separate the flow that they would not be quick to merge it back together.