I agree that domain knowledge is invaluable. But in the examples given, the difference in domain knowledge between local talent vs remote may not justify the 5x salary.
Perhaps not all the nuances, and many aspects are arbitrary choices and only the spec would reveal what the business unit chose, but there's a lot of domain knowledge required to be productive.
If we need to outsource stuff, that has to be to some outfit that has developers experienced with banking nuances, and often times they are more experienced than internal devs (because they have worked on this parictular tricky corner of banking for multiple different institutions), and if we hire devs from outside the industry, we expect the first 6 months to need a lot of handholding because they don't know the nuances of banking and they can't be productive at all until they learn at least most of them, because no realistic spec will be sufficient for a programmer without a domain knowledge, at least not in the financial domain.
It really bothers me because I generally get put on projects with little acceptance criteria and not something I've done before, yet I deliver on time and the end user is very happy because I take the time to ask good questions up-front. Why can't someone deliver something that makes me that happy.
On the topic of communications. I've consulted on projects where I've said that something I noticed should be done a specific way, even though it was not part of AC, technically worked correctly, and making the change would be feature creep. My advice was ignored. Weeks later the end users kept complaining that the software was difficult to use and could not communicate what they didn't like. Since they refused to use the software and they refused to accept it as it was, I was brought back in. I sat down, found out what work the end user was doing, and did some of that work. I literally did someone else's job. I used the software. I made a huge list of areas for improvement. The PM agreed to everything. All of the changes were made, the end users were now saying it was awesome to use.
To summarize, learn to read between the lines of the acceptance criteria. Would you want to use the software you're making? For me, small issues annoy the heck out of me. I notice these things. End users tend to just say nebulous things like "it doesn't work well".