The Waters special report sponsored by Apama that was published recently, ranked "risk and compliance" as the number one application of event processing in financial institutions. Today TIBCO also published in its Blog under the "event processing" category its view on compliance - entitled: "The Y in comply". It gives the view that people comply better when they understand the rationale of compliance, the example given is compliance with regulation in the food industry that employee has to wash hands before putting on gloves.
I agree that people comply better when they think that the regulation makes sense, however, my own subjective impression is that in the current culture, compliance became goal of its own whose sole reason as somebody described it "to get the regulator off my back". Thus employees are required to do things that they don't see any reasonable explanation why they should do it, and IT systems check that they are doing it. Here, event processing is used since in various cases auditing is event-driven, it is time sensitive an often involves calculation in time windows, and in some cases online auditing on the fly is required. The business value sometimes is just pleasing regulators, but this is often a great motivation for managements to take it very seriously... Anyway, technologies are used for strange reasons sometimes...
4 comments:
I spent several years designing, building and implementing compliance systems for US and British financial regulations. CEP alone can't do the job for a simple reason. Compliance requires reasoning over event and historical data. In most cases, a compliance system that does fraud detection, government regulations and simple restrictions has to handle three types of data: events (ie tickers/feeds), historical aggregates (usually from a cube) and metadata.
Given that CEP and ESP primarily deal with simple streams and doesn't handle complex "join-like" operations, CEP is only ideal for simple restrictions or VWAP like aggregates for trade execution. Having read the actual laws and implemented them, most of the cases do not fit CEP. Anyone that says otherwise is just looking to sell software licenses and is lying.
Hi Woolfel (actually Peter?)
You are right in the sense that engines that do aggregations don't on streaming data are not enough for compliance applications, but you probably have in mind certain implementations. Today many solutions in the event processing space (whether based on commercial event processing platforms or self-built) support blend of operators on streaming data and historical data, and support "join-like" operations (patterns), thus they are used as part of compliance solutions.
Opher
Yes, I am peter.
I agree it can be "part" of the solution. What I've seen is sales people try to paint CEP products as "the solution". To be fair, I've also seen business rule vendors claim to be "the solution" for compliance in the past. Sales people "over selling" their product to close a sale is not unique to any particular software.
Having connectors or integration components is a good first step, but that's just the beginning. Sometimes diversification rules have to blend a variety of data to calculate the risk and compliance. It might include the current VWAP, public ratings, user defined aggregates, estimated weight/value, regulations and business rules. How one connects all these components into an efficient compliance system is far greater than just catches phrases like "continuous compliance."
I understand it's a marketing term, but we do a huge disservice by over selling CEP in this way. The business rule industry learned that lesson the hard way.
Hi Peter.
You are right that that there is a lot of overselling in the industry - I think that "analytics" is also an oversold term, Gartner calls it "peak of inflated expectations" in the hype cycle. If you read my Blog you may realize that I stay out from the term CEP, exactly because it became "marketing buzzword", and use "event processing" in broad sense, not necessarily identical to capabilities of any specific product, moreover, most event processing solutions are hard coded, and they are still doing event processing. Event processing is not just aggregation like VWAP, but also event filtering, transformation, pattern detection, anomaly detection, and more. And you are right - it does not solve all the world's problems, however we have developed a continuous compliance based on event processing in the past, and it provided significant value, since detection patterns within sliding windows was part of the required functionality (and yes - retrospective processing of historical events was also part of the solution).
Stay well,
Opher
Post a Comment