There are obviously alternatives to making the second factor of two-factor authentication be the user logging in from a trusted device. There are also certainly alternatives to authenticating that a certain device is in the control of that user before it's registered as a "trusted" login device for that user besides the security code method. *The hard question is whether there are any of either methods that are clearly, unambiguously better in terms of usability, across your whole population of users. While also filling the heightened level of security needed for a banking site
To be honest, I kind of doubt it.
Let's illustrate by example:
Some alternative methods of 2FA to authenticating a user robustly on first login from a specific device/machine then considering it as "trusted" for logins thereafter:
One-time PIN authentication token:
Doesn't require the user to have a network-connected phone or PC to, say, get a security code. Does require the user to physically carry around the token wherever they might want to access their account. (Also requires bank to distribute them. Probably wouldn't make financial sense to do just for users only to get a code the first time per device they wanted to use, assuming you did want to keep the trusted-device scheme. But, OTOH, if you wanted to go for a more secure arrangement where users need a code at each login it might.)
USB 2FA device of some sort:
May not require user to fool around entering codes & such, but obviously requires users to physically carry around, just like a token. Plus, may only be able to use to log-in from machines/devices with a full USB port.
Making user get a security code via an SMS or authenticator phone app:
Doesn't depend on what device user logs-in from, but obviously is dependent on user having their phone with them. Essentially what you're doing now to authenticate before adding a new device as trusted, except that you would be making the user get a code from his/her phone for every login.
Making user get a security code sent via email:
Would allow user to log-in from any machine/device where he/she could access their email. Would also require each user to get a code for each login, plus go through hassle of logging-in to a separate account/service and then logging-in to yours. (Not even mentioning security implications/drawbacks, of course.)
Checking whether the user is logged-in to another service that you trust the authentication security of:
Lots of services nowadays make use federated identity from a larger, 3rd party-service, of course. So far, they've typically been used as a sole authentication factor by services that don't require particularly strong security (like blog commenting) and don't want the hassle of setting up an authentication scheme themselves. But there's no technical reason (that I know of) that you can't use it as a second factor. This might avoid user impatience with an extra-authentication factor when a user is logging-in from any device where he/she is typically logged-in to the other service. But where they aren't, users might be as or more irritated by needing to log-in to another service as they would be using a security code.
Smartcard:
Deploy a USB portable smartcard reader and smartcard to each user. Would, of course, require user to have both whenever & whereever he/she wanted to login.
(-Doable-but-not-considered: Using facial recognition as a biometric second factor from any device with a commodity camera. Flexible, but laughably insecure. Maybe if/when more devices will be packing RealSense or similar camera hardware... )
I'm sure you get my point. If there were an obviously more usable, practical-to-deploy, and at-least-as-secure* method of doing the second factor of 2FA out there right now as the security code---> trusted device way it would probably be well-known and in very wide use. Instead, that model has fallen into a role as a semi-defacto standard among the biggest services on the net that use 2FA. I think that's largely because asking somebody to take a few moments to use a security code the first time they log-in from a device (and perhaps make a few especially sensitive actions within the service) is a pretty minor imposition.
The occasional grumpy user with zero care about the security of their banking service notwithstanding. :)
Oh, about the checkbox to giving the user the chance to decide whether a device should be deemed "trusted", while it is an extra thing that some users will puzzle over and the mental attention needed to choice that inspire a little bit of that feeling of friction, many users even today still log-in to their banking sites from devices they share or don't otherwise control. Even, yes, from publically-shared computers. [Sigh.] That's something that at least deserves serious consideration when thinking about whether to have the checkbox and, if so, what the default state of it should be. (As many, if not most, users will just leave whatever the default check or non-check is alone.)
*Personally, I'm not a huge fan of the device-trust mechanism in something like a banking-site role. There are some potential issues with it that make it an arguably less-secure mechanism than requiring an SMS or authenticator app code. But I understand that, in the real world, sometimes one has to trade a little security for a larger improvement to User Experience.
