As a bank, if you provide an SDK for 3rd party developers to use, you are not in a position to review the app before release. Only Apple/Google gets to see that code.
The proper solution would be either 1) the ability to register 3rd party libraries with apple and require some kind of integrity check before approval (but even then, the 3rd party app could override library methods at runtime), or 2) code signing the binary blob library separately for every 3rd party developer (but then the problem is enforcement of where developers get the library from -- how do you verify SDK integrity from the bank server side?)
The fundamental problem is that, as soon as you give 3rd party developers the ability to natively integrate with your service via an SDK in their own app, you are playing a cat and mouse game.
It depends if that SDK has an API key barrier or not. I mean if I'm providing 3rd party access, I want to see how each individual app is performing and what it is doing.
But yes, aside from that potential difference, I understand what you're saying.
The presence of an API key is not sufficient to verify the client loaded your SDK with the same checksum as the one you released. The client can modify the code of the SDK to perform any arbitrary logic, including bypassing integrity checks.
The proper solution would be either 1) the ability to register 3rd party libraries with apple and require some kind of integrity check before approval (but even then, the 3rd party app could override library methods at runtime), or 2) code signing the binary blob library separately for every 3rd party developer (but then the problem is enforcement of where developers get the library from -- how do you verify SDK integrity from the bank server side?)
The fundamental problem is that, as soon as you give 3rd party developers the ability to natively integrate with your service via an SDK in their own app, you are playing a cat and mouse game.