I was wondering if this could be a security issue for banking application and if so, why? What are the risks if I allow it?
You should only control what can matter. The localisation is always off on my smartphone, unless I am actually using it. Not really that I want to hide it, but I can hardly understand why a banking service could be interested in it. And I know that a legal enquiry would immediately get it from my operator. The same if I use a (public or not) Wifi access. I assume that my bank also knows it, so they do not know it but know that they could get it if an attack came from there.
Things are different when you use Tor or some other well known(*) proxies that are used for privacy, because now even legal enquiries cannot easily find where the connection came from, it they even can. So IMHO I would neither be disappointed nor even surprized if my bank rejected all Tor accesses or required at least a strong second authentication factor (nor a secret question...) for security reason. After all I have never entered a bank office wearing a mask, and I would expect that they do not let me in.
So reject Tor accesses if you want, but please do not concentrate too much on geolocalisation for a banking service. What matters here is to authenticate the clients not where they are. Anything that can prevent access point identification is suspect, but simply not giving localisation is not.
(*) Not all proxies are the same. Do not reject corporate proxies for example...
Are you talking about faking location services in a browser or on a mobile device, or connecting through a VPN to appear to spoof IP-based geolocation?
Personally... if my bank asked for access to geolocation data from my phone for anything other than finding a branch or ATM, I probably wouldn't be using that bank. As for IP geolocation checks... I'd use that data to add weight to fraud detection.
If there are enough factors to suggest the request is not by the customer, then block as potential fraud. But current location alone probably shouldn't be enough, because people travel. Did they suddenly move from one country to another faster than one could travel by plane? Are they connected from two countries at once? Is the user-agent of the connection different than what the normally use?
Add up all these little things and set a threshold at which a block action will take place. If you want an example of how this would be structured, email anti-spam systems are a great example to look at. There's not one single factor to decide if email is spam... it's a system of different checks that work in concert with one-another.
If VPN services are a concern... add them as a factor in the system. But many people will be connecting to a VPN for banking if they are on public WiFi. I don't think that alone would be a legitimate reason to block a request. I'd probably set the system to adjust the weight of the factor based on whether the user normally uses a VPN or not.
Malicious individuals attempting to break your application will probably fake their location and hide their public IP through VPNs, Tor and/or proxies. Not blocking users faking their location could expose you to their attempts
On the other hand, faking location is usually something a user worried about his privacy would do.
Also note, that this kind of controls are made client side of the application, so a malicious individual with enough knowledge in reverse engeneering may bypass that kind of filters, while a legitimate user probably won't do it
You should balance what do you prefer, block possible attackers and possibly legitimate users faking their location or expose your application to those attackers