I believe that you are mixing up applications logic with business contracts logic.
Let us take an example here. Assume that you are establishing a Hyperledger Fabric Network for 4 parties and there will be a rule which would define how the assets would be distributed amongst the participants. Let us say that the parties are named A, B, C, and D, and according to the rule, the distribution happens like 40%, 30%, 20%, and 10% respectively.
Now if all the parties work at different organizations, implement a chaincode that will further apply a business rule on whoever submits a transaction. ACL can also be implemented to make sure that a party is not able to query for the balance of another party in the blockchain network.
When you can have only one peer with chaincode deployed, the channel which configured for all 4 parties will invoke the chaincode when you send the transactions. You will have to decide which org will host and run the peer and the chaincode. The 4 parties do not really trust each other as they would like to host their own peer and invoke chaincode against their own peers. And in order to prevent each party from tricking each other and reducing the influence of adversarial/non-deterministic behavior, they agree on endorsement policies which actually make sure that peers of other parties also receive the same results as you during the simulation.
Now back to your question, peers are used to simulate transaction against current state and sign on the results, send results back to the client which aggregates endorsements based on policies and submits results to the ordering service which cuts blocks and deliver them to the peers, which will validate correctness of transactions in the block and eventually commit them to the ledger updating state.
Therefore your chaincode should encode the notion of clients/users/persons among which you will distribute assets, those users could be mapped back to the client application which might be enrolled into different organizations, hence having different certificates signed by appropriate org CA. Finally, you will be able to leverage GetCreator API of the chaincode to understand which client invoked the chaincode and apply business logic and access control based on business logic you defined.