So if I understand correctly, you are looking to create an abstract model that could then be applied to a variety of business cases, e.g. position management. In that context, would the events look something like...
- Order event [type=order, subtype=open, details[id, trader, issue, side, qty, price, dest] ]
- Order closed event [type=order, subtype=close, details[id] ]
- Execution event [type=order, subtype=execution, details[id, qty, price] ]
With the monitoring piece containing logic like...
- not dest in authorized[trader, issue] send alert("trader not authorized to trade %s at %s", issue, dest)
- position[trader, issue] > position_limit[trader, issue] send alert("trader position limit exceeded for %s", issue)
- position[trader] > position_limit[trader] send alert("trader position limit exceeded")
- position > position_limit send alert("firm position limit exceeded")
This is the type of thing that should be possible, although commitments have the concept of debtors and creditors in terms of the obligations, and the ability to delegate obligations, so should be possible to construct quite complex governance situations around a definition of the high level business process (i.e. the choreography). So another example could be that, by entering into a business transaction between two parties, one party is obliged to provide legal documentation to the other - this obligation could be delegated to other parties, and the obligation may be discharged through different paths through the choreography, or even as part of different business processes (choreographies) that may be enacted at a future date.
The problem is that my basic understanding of the concept is looking for real world examples to illustrate whether it could provide real business value. In a general sense, having the ability to essentially 'decorate' a business protocol with assertions/commitments, etc, and then optionally define business rules that can operate on that information, should provide great flexibility - as it externalises the responsibility from the actual business process. Currently a lot of this governance logic is probably built into systems, potentially being hard-coded, so unnecessary work and inflexible solution. So I feel like this would be a good general technique to support, but would be useful to identify a number of real world business problems that could be solved.
So I think position management, or in a more general sense risk assessment between counterparties, is a good candidate solution. But would be good to find others......
Well you still might have something there. In the securities business, most transactions are "cleared" through a third party. Depending on how the business is setup, the clearing agent may prevent a trade from occurring for various reasons (e.g. exposure). Here's an example:
Brokers A, B. Clearing Firms X, Y. B agrees to sell 100 FOO @25 to A. The trade is reported to a trade reporting facility (TRF). Here's where things can get interesting.
- X does not have an agreement in place for B/Y. The TRF rejects the trade.
- X requires manual "lock-in" for all trades with B, clearing through Y. A message is sent to X, asking to lock-in the trade. The trade goes through, but may not clear.
- X has an agreement to automatically lock-in all trades for A executed by B, clearing through Y. The trade is accepted and should clear normally.
- X requires manual lock-in for all trades > size. The TRF holds up the trade, pending approval. (In some cases, the TRF may hold up large trades, giving the clearing firm the opportunity to reject it, i.e. the TRF may also hold up the trade, depending on its policies.)
Take the above and replace the B/Y side with each of the above (e.g. Y does not have an agreement, Y must manually lock-in, etc.).
Each of those is an agreement between the brokers and their clearing firms, with the TRF acting as the facilitator. The clearing firm may reject trades.
The above is probably not exactly right, but the gist is there.
Not sure if that helps or not.