One solution could be to have private information outside of blockchain, and enable each bank to query it's private information by an API, directly from your chaincode, and have a shared channel among all the banks that share information through chaincode calls. Of course all APIs must be secured to be only queryble by it's own bank.
Another solution without having to implement things out of your blockchain would be to use private data collections, which is an improvement made to Fabric in version 1.2. More information here: https://hyperledger-fabric.readthedocs.io/en/release-1.2/private-data/private-data.html
Update:
Is it safe to call external apis from the chaincode? How would I maintain secret keys/tokens?
Yep, it's safe as far as you secure your communications and your endpoints. An easy solution would be to have your node and your private data store inside the same network, inside a firewall. In that way you wouldn't have to worry about security inside your applications.
To implement this using Private Data, is it possible to maybe have an array of strings which are identifiers for the banks in the Client struct, and the client can invoke functions to allow more banks, and when banks try to query a Client the code checks that array if the bank's identifier is included there or not?
It seems to me that you are in the right direction, but I would implement it as a JSON file, more than an array with access rules, stating that for BankA, BankB has access to this and that functions and so on, and also you can set levels of visibility in the information, and then implement the logic that reads and uses that config in your chaincode. In production, each node will have to have its own config file, but for development you can have a single config file with all the rules.
Update 2:
Is it possible for someone from an organization to 'query' the ledger or read it's state directly and NOT through the chaincode?
Short answer: yes, it is possible. Whatever gets written in the blockchain, would be readable by administrators of peers, and anybody who has control over private keys. BUT here is where architecture comes into play: if you don't need something written in the blockchain, just don't write it. It depends on what you want the blockchain for. If it's just to attest that an information has been shared, just save the necessary information: 'bankA shared info about userB with bankC'. The actual info doesn't have to be saved in the blockchain. If you need to have the info in the blockchain and you want to keep it private, I think the best solution is using private data collections, and be awared that in fact private data is not subject to consensus, because private data gets saved in a side DB only in the peers/organizations involved in the private transaction, not in every peer.
