Your whole premise is surrounded by the threat a client browser would not properly validate a server certificate... come on... really?
They want cryptographic proof of client identity. That means somehow the client has to prove they are the real user and not an attacker who intercepted the connection somehow (which, again, is completely possible). Client certs are a way to verify with each message that the user themselves, using their private key, validate what's going on, and that the message they validated came from the real server and not a fake intermediary.
This is different from 2fa because 2fa is authentication of identity that only happens once and does not provide cryptographic proof of identity. TOTP will give you something closer, but it's still a "dumb token" that can be intercepted.
tl;dr
2fa:
Client request 1: "Gimme $5."
Bank reply 1: "Who are you?"
<man-in-the-middle starts listening>
Client request 2: "StrawberryNewtonManicDresser"
Bank reply 2: "Okay, you can now use session ID 1234 to request more money."
MITM request 1: "Gimme $100000."
Bank reply 1: "Who are you?"
MITM request 2: "Session id 1234."
Bank reply 2: "Okay, here's your money."
Client request 1: "Gimme $5."
Bank reply 1: "Who are you?"
<man-in-the-middle starts listening>
Client request 2: <'Gimme my money.' ^ PRIVATE_KEY>
Bank reply 2: <verifies CR2 against stored client cert>
Bank reply 2: "Okay, you can now use session ID 1234, starting at iteration 2, to request more money."
MITM request 1: "Gimme $100000."
Bank reply 1: "Who are you?"
MITM request 2: "Session id 1234, iteration 2."
Bank reply 2: <checks MITMR2 against stored client cert, is not valid because iteration 2 wasn't signed with the client private key>
Bank reply 2: "You're a faker, get lost."
It should be noted that carders, whom normally get their Bank credentials from malware on a user's device, can already inject commands into active valid sessions started by the user, so verifying the user's identity is completely pointless in this case.
The victim does not know they are being MITMd and enters the 2FA code.
The bank could encode the permission (amount, beneficiary, read access, etc with an expiration date) given into an OAuth bearer token, and the app can use the token to do exactly the things that the user consented to.
If they tried this at a Canadian bank, every non-technical person would immediately switch to a competitor and they'd lose more money than they'd save via fraud prevention.