Cache, not cash.
But still, with every software handling figure rigging differently, there really needs to be at least one rigging standard that a given format plugin converts to and from within each application that can use that plugin. Daz Studio and Poser are drifting apart as far as what type of figure rigging they use, Max has its own preferred format, and I'm sure TrueSpace has a completely different format. There needs to be a plugin that forces a universal skeletal system, and that carries with it a specific set of commands for the posing of a figure in any app that can read the plugin.
The accepted/adopted rig/animation interchange standard is the FBX file. It already does exactly what you are suggesting
But there are limitations. This isn’t down to the FBX but to do with the complexity of the task (animating deformations) and the different ways it has been implemented in various bits of software.
e.g. exporting FK animation on a set of bones FBX will translate it beautifully as baked, key-framed rotations that can be read and translated by all. The problems come when you want the more complex stuff such as the way a bone deforms the mesh around it.
Every single 3d software uses a different method and technique to deform a mesh (particularly at a joint) what you see in one software is going to be different in another at the joints.
e.g. some software use joint compensation algorithms to inflate the edges of a joint to prevent pinching at an elbow or knee. Some of these algorithms use a constant volume technique others use a resistance model. Neither of these algorithms can be translated into data that could be either stored in an FBX or understood by another bit of software. As they are a core part of the program and its animation paradigm.
Now lets think about IK. What’s the betting that two bits of software use the same solvers for IK? Or provide the user with the same level of control over the implementation within the software. There is no guarantee that a leg/arm bend in one bit of software will be the same in another unless both bits of software use identical IK solvers with the same set of resistances along the bone chain with the same set of parameters exposed to the user.
You can get a rig, a set of controllers and IK goals all carrying animation between all the main bits of 3d software. These elements work just fine. What wont work properly is the deformations on the geometry. It will require user input to manually fix the propriety techniques used in one software to the propriety methods used in the other (if there is even an option to to do that within the target software).