The comments gave to understand (I think) that you want to stop using SQL to use LINQ.
On top of everything Vinicius said, you shouldn’t do that if you want the possibility to use several different databases. Perhaps the most notorious limitation of LINQ To SQL is precisely in not being able to work with several banks.
Whether this is your intention should create a mechanism of your own or use some ready that abstracts the differences between the various banks.
I won’t say I recommend it but you should take a look at Entity Framework, this is the ORM which is recommended by Microsoft in cases like this. On the Wikipedia page is a list of other options like the Nhibernate which also has reasonable use.
It’s not so easy to learn to use them but it should give the result you expect.
I don’t know these products well enough to tell you if it’s easy to work with stored procedures the way you intend to use these technologies.
With EF it is possible to use LINQ but in the LINQ To Entities model.
If you prefer something simpler and can continue dealing with SQL you can take a look at Dapper. In general I prefer simpler ways. But of course in this case you have to know how to work with the various banks without causing confusion. I personally find it easier to do this way but most programmers find it easier to leave a framework ready to deal with this.
I reinforce the idea already reported by others who stored Procedure is not a good idea for what you want. Much less will bring the benefits you are reporting that you will have. I would say it will probably bring opposite result in some situations.
LINQ to SQL and Entity Framework do it for you. What is the need to change a schematic that works for any database for a schematic that works in one?
– Leonel Sanches da Silva