In order to solve the "Additional data" issue, I think you can make things a little bit dirty and just share sort of "AdditionalDataRegistry" or a "SharedDataRegistry". This registry will contain or will proxy to any repo needed to get additional data requested by rules. It will be injected in every rule that can have read-only access to that shared data: obviously can have access to data that is not relevant to the rule itself but if it's exposed as read-only I don't see any problem. In this way, you can avoid handling all the possible dependency permutations for each rule.
Another thing you can do is to use some scripting language (Python, Lua, Javascript) to implement strategies for these calculations and store these scripts on a database. They will be evaluated at runtime by a Python/Lua/Javascript engine hosted on your application. The main benefit is that you can add and modify strategies at runtime without any new deployment. The cons are that those scripts are more difficult to test and you have to find a good way to expose data to the scripting language engine.
Need to say that it should be considered only if it really worth the effort and a need of dynamic rules changes are really part of your business and not something happening due to bad organization or bad project management.