The short answer: You cannot work against this by trying to control the client.
The long one:
When creating an API that gives a user access to your data, the user will be able to call that API and its endpoints to access that data. This is by design and what you want, otherwise you would not give them access to your API (and that data) in the first place.
What you want to do is stop the user from accessing your API using anything that isn't your application. As you've correctly identified, giving a user access to your application allows them to reverse engineer it and find out how to call your endpoints.
What you've tried so far boils down to: 1. Generate some data (presumably some hash) in the client to send along with a request to verify it 2. Obfuscate your frontend code to make reverse-engineering harder 3. Setting a restrictive CORS header
From these three methods, the first two basically boil down to "You want to make it harder for someone to reverse-engineer your application". This is what the security field refers to as ["Security through obscurity"][1] (also see [CWE-656][2]). It is generally not seen to make your application more secure, at most it will gain you some time until your application can successfully be reverse-engineered.
CORS functionality, the third point, is the only one that has provable merit here, though as you noted it is also not a magical solution to all your problems. What a well-designed CORS policy would do for you is prevent another website to send a request to yours to perform an action the user may be unaware of. It does however not stop me from creating an application that intentionally sets the Origin header to be the same as yours, bypassing that protection.
Now that we've established why all three of your attempted methods do not work for what you're trying to do, let's look into what you can do and what you should do:
In summary, you are barking up the wrong tree. You are trying to have your client be the only way to interact with your API to protect data (?) while it is not possible to trust the client sending information. What you should do is fix security problems where you can control and fix them (server-side) instead of trying (and inevitably failing) to control the client.
What you should be doing instead is to take a step back and look at what you're ultimately trying to achieve and then define what you should do depending on it:
Are you trying to protect...
- **Confidentiality**? Add authentication and proper authorization to your application to prevent users from gaining access to data they shouldn't be able to access in the first place. This boils down to "Does user X with their permissions need to be able to access Y? If not, require certain permissions to access Y that X does not have." - **Integrity**? Make sure your users use the correct application downloaded from the correct source (e.g. provide checksums to allow them to verify it by themselves). This is the hardest part and what cannot really be done automatically with the threat model you're defining (as in, there is no singular best option to do this). - **Availability**? Add sensible rate-limits and other checks to prevent someone from clogging up your server with requests to take it down.
As you've mentioned financial institutions, they have not solved this problem and will not be able to either as long as code is executed on your machine they do not control. Outside of possibly some laws and Safe Browsing etc., nothing technically stops me from creating a website right now that impersonates my bank and shows data from it using login information it asks of me.

[1]: https://en.wikipedia.org/wiki/Security_through_obscurity [2]: https://cwe.mitre.org/data/definitions/656.html

So what you're after is some kind of server side authentication mechanism that will handle the authentication and authorisation aspects of a mobile application?
Assuming this is the case, then I would approach it as follows (but only 'cos I'm a Java developer so a C# guy would do it differently):
**The RESTful authentication and authorisation service**
1. This will work only over HTTPS to prevent eavesdropping. 2. It will be based on a combination of [RESTEasy][1], [Spring Security][2] and [CAS][3] (for single sign on across multiple applications). 3. It will work with both browsers and web-enabled client applications 4. There will be a web-based account management interface to allow users to edit their details, and admins (for particular applications) to change authorisation levels
**The client side security library/application**
1. For each supported platform (e.g. Symbian, Android, iOS etc) create a suitable implementation of the security library in the native language of the platform (e.g. Java, ObjectiveC, C etc) 2. The library should manage the HTTPS request formation using the available APIs for the given platform (e.g. Java uses URLConnection etc) 3. Consumers of the general authentication and authorisation library ('cos that's all it is) will code to a specific interface and won't be happy if it ever changes so make sure it's very flexible. Follow existing design choices such as Spring Security.
So now that the view from 30,000ft is complete how do you go about doing it? Well, it's not that hard to create an authentication and authorisation system based on the listed technologies on the server side with a browser client. In combination with HTTPS, the frameworks will provide a secure process based on a shared token (usually presented as a cookie) generated by the authentication process and used whenever the user wishes to do something. This token is presented by the client to the server whenever any request takes place.
In the case of the local mobile application, it seems that you're after a solution that does the following:
1. Client application has a defined Access Control List (ACL) controlling runtime access to method calls. For example, a given user can read a collection from a method, but their ACL only permits access to objects that have a Q in their name so some data in the collection is quiety pulled by the security interceptor. In Java this is straightforward, you just use the Spring Security annotations on the calling code and implement a suitable ACL response process. In other languages, you're on your own and will probably need to provide boilerplate security code that calls into your security library. If the language supports AOP (Aspect Oriented Programming) then use it to the fullest for this situation. 2. The security library caches the complete list of authorisations into it's private memory for the current application so that it doesn't have to remain connected. Depending on the length of the login session, this could be a one-off operation that never gets repeated.
Whatever you do, **don't try to invent your own security protocol**, or use security by obscurity. You'll never be able to write a better algorithm for this than those that are currently available and free. Also, people trust well known algorithms. So if you say that your security library provides authorisation and authentication for local mobile applications using a combination of SSL, HTTPS, SpringSecurity and AES encrypted tokens then you'll immediately have creditibility in the marketplace.
Hope this helps, and good luck with your venture. If you would like more info, let me know - I've written quite a few web applications based on Spring Security, ACLs and the like.
[1]: http://www.mastertheboss.com/web-interfaces/273-resteasy-tutorial-.html [2]: http://static.springsource.org/spring-security/site/features.html [3]: http://www.jasig.org/cas