Legit for banks tends to just mean that basic security rules are being enforced, like app separation and credential protection. Technically, what banks and other fraud-sensitive services care about is not whether your device allows
you to do things or not, but whether it allows malware to do things. If malware can get root then it can steal credentials that would let it impersonate the user and initiate cash transfers.
That's why Android devices allow you to obtain root and unlock the bootloader but factory reset the device whilst doing it. Banks don't care about that feature because it's not accessible to malware and even if someone does it (e.g. because they physically swipe your phone for a few minutes) the login cookies are wiped in the process.
The problem with rooting or jailbreaking outside of this process is that it could have been done by malware instead of the user - you can't tell post-hoc - and even if it was done by the user, rooted phones often have semi-broken security systems e.g. they turn sudo on or users run random apps as root that were grabbed off anonymous GitHub accounts. From the bank's perspective all this is highly risky both for you and more importantly for them, as ultimately weak security = fraud = reputational and financial risk to the bank.
Still, realistically, what banks care about is devices that were silently rooted by malware (or physical thieves). Individual Linux hackers are such a tiny number of people they'd probably be OK with just letting those people get rinsed if they run malware. The problem is, how do you know which is which?
A meet-in-the-middle compromise for the banking use case is for some neutral standards body to certify OS builds against a set of concretely specified security goals, whether they're open source or not. There's no specific technical problem, it's a social issue that it's expensive to do such audits and open source hackers don't want to pay for things. LetsEncrypt solved the same problem with SSL by just brute forcing the issue with money, which may be the way Google/Apple choose to go here. If you want root on your device to customize your window manager or something then no, don't give yourself root, instead spin a deterministic OS build with whatever changes you would have made using root, ensure the OS build is secure and then submit it for auditing. Done properly the audit can be mostly automatic, e.g. if the SELinux rules match the set found in a base distro that's already trusted, then you can know that credential protection/debug APIs are configured as before, so then you can wave through changes to non-critical OS processes.