Regulatory Reporting projects – Five things to watch

What have we learnt from the recent flurry of Regulatory Reporting activity? Here we share our combined experiences and hopefully give you some insight into the potential problems and pitfalls that may await you if you are required to deliver such a project to typically tight timescales.().

1) Know your business – Scope and Prioritise

When you are deciphering the reporting requirements you must pay particular attention to how this applies to your historical and ongoing trade population. It is especially useful to look at what is required for day 1 and what can be deployed in the days and weeks that follow.

Regulatory Reporting projects require a lot of intricate mapping and translation work. This can be laborious and time consuming so make sure you are only working on the trades that you actually do. Your source trade capture systems will no doubt be capable of handling all manner of complex trading activity and may well deploy complicated, inconsistent and unexpected workflows in order to deliver that trading activity. So why waste time mapping and translating a complex Calypso workflow for business activity that you currently don’t engage in.

Scope and prioritise. Tackle your highest volumes first and start with your new trade activity. Tackle your post trade events next, again starting with your highest volumes. For trades and events that fall outside of your priority list, consider implementing control processes in your front office that will coordinate short term trading activity with your post day 1 implementation schedule.

2) Who are you reporting for?

Be aware that you may not only have to report your own trades. For instance, under some reporting regimes (EMIR for instance) it is possible to delegate your reporting to another party. This is a very tempting proposition for smaller buy-side counterparties and may well present the potential for further cementing of trading relationships and open some new revenue streams for the larger players. So make sure you engage your counterparties as soon as you possible to gauge the demand for delegated reporting.

Obviously, this will present a significant challenge in maintaining the static data that will support the required decisions to trigger reporting. This is especially complicated for those firms that are outside the reporting regime but deal with counterparties are subject to it. Your golden source for counterparty data is probably a good place to start. If you’re starting your reporting project late, as they typically do, then it’s likely that you’re going to build a tactical solution to support your reporting. You’ll no doubt have different ids for the same counterparty depending upon the trade capture system that you are dealing with, so your domain model will need to cater for that.

In short, you need to scope the demand and determine where this data will live early and start the build and sourcing the information with close liaison with your counterparties.

Finally, you need to pay attention to any internal back-to-back trades that cross into the reporting regime in question. Decide which side you need to report and maintain your static data and triggering accordingly.

3) Getting your connectivity in place and smoked early

One of the areas that always seems to be unplanned in regulatory reporting projects is the testing infrastructure. Working on understanding the requirements under the regulations, dealing with clients, managing their expectations and mapping to your reporting language are all crucial tasks and needs to be done. However, without a suitably stable, integrated and easily managed testing infrastructure, you won’t be able to test your reporting process. The later this is left in the life of the project, the less control you’ll have over your environment when it does arrive and you will lose significant testing time to drive out your edge cases.

Another area that you want to think about are the tools that you use monitor this environment and track down issues. Can you easily find a message in your stack? What level of logging are you going to apply that will assist your team in investigating and fixing problems at code, message and process level? Having a named environments manager is a very good start to nailing these questions and regular feedback across the project team will also help significantly.

Finally, make sure you have active, working access accounts to the regulators portal and queues. Don’t believe for a minute that getting access at the 11th hour to run some final “shakeout” testing will suffice. It simply wont. Whichever way you look at it, whatever you do, it’s best to do it early.

4) Not-reported by mistake? Have another go.

Regulatory reporting, like any other STP process, is highly dependant upon accurately maintained static data store. For instance, under EMIR, it is possible to delegate your reporting to your counterparty (see 2 above). The business logic that defines this relationship needs to be encapsulated somewhere in your internal counterparty static data. Your reporting platform will receive the trade message from your trading platform, check your static data in order to determine whether to report or not and then carry out the required processing. So, if your static data has incorrectly set up and this makes the relationship “non-reportable” you will get a lot of not-reported trades that should have been reported. So what can you do about that?

Your design needs to be able to handle this situation elegantly. Not-reported trades should be visible in some way (most likely through a web-based browser solution) to your Operations teams. They need to be able to quickly identify that the static data has been set up incorrectly. Once the static has been corrected, your design must also support the replaying of these trades – and probably in a bulk fashion also.

This same mechanism can be expanded to encompass your Acks, Waks and Nacks coming back from your reporting partner. Again, immediate visibility of issues for the Operations teams is critical here. If you’ve got your design right, then the replay mechanism will handle these situations for you for free.

Of course, if you’re really clever, and want to impress your business users, then the very act of correcting static data could be used to automatically trigger the replaying of those trades that were impacted by the change. I’ve written about this in the past. Clever stuff and worth looking at, but be cautious in your approach.

5) Production Edge Cases. Be Ready.

It’s an unwritten law of software development – “Real data is a law unto itself”. No matter how extensive your preparation, analysis and testing has been, when you go live you’ll find more edge cases. No doubt you’ll have found lots of internal system integration edge cases after having built out your regression testing packs (I’ll blog on that subject soon) and tested your solution extensively. However, don’t be fooled into thinking that you’ve got them all.

I’ll share an example from a recent EMIR project that I was involved with. The problem statement was that if you had agreed that your counterparty was to undertake regulatory reporting on your behalf, a reconciliation process must exist in order to ensure that reporting had taken place and was accurate. The solution implemented across the industry is the Allege process, whereby when a report is made to the regulator pertaining to a derivative trade, the non-reporting party is sent an Allege message, detailing the trade details as provided by the counterparty. This would then allow reconciliation processes to run internally and for any breaks to be highlighted. An elegant solution.

Unfortunately for us and our client, we’d interpreted that a “unique message-id” actually meant a “unique message-id”. We constructed our client’s message-ids to be unique, incorporating a number of uniquely identifying features. However, on go live day, it became immediately apparent that some of our client’s counterparties weren’t being as precise with their message-ids they should have been. Not only where message-ids being reused, they were also being used across completely different trades. As you can imagine, this caused some issues in our Alleges message store where unique means unique. Luckily years of experience had prepared us for just such edge case discovery and we were geared up ready to respond.

So be ready to react to the production edge cases, especially where aggressive timelines have prevented you from testing with external parties.

()

Redhound are happy to advise on all aspects of business analysis modelling, including reference data, business process and trade flow.

Our live Cloud-based demo integrates a Eurex clearing feed into a trade flow with complex routing rules, and is a working example of our modelling techniques.

Get in touch!

We hope this post has been helpful.

If you’d like to find out more about our approach, the technology we use and the partners we work with, get in touch

Posted in Business Rules, Connectivity, Data Flow, Data Mapping, EMIR, Message Queue Software, Messaging, Regulatory Reporting, Replay, Routing Rules, Smoke Testing, Static Data, STP | Tagged , , , , , , , , , , , , , , , , , , , , | Comments Off on Regulatory Reporting projects – Five things to watch

Decision Table Rules Part 1 – The Exclusivity Problem

Summary

How the use of decision tables for modelling business rules gives rise to questions about whether rules are mutually exclusive.

Background

We have recently been using a form of decision table to classify a population of messages. We have constrained our decision table design in the following ways:

  1. We only allow conditions to have Boolean values
  2. We only allow our rules to specify either a Boolean constraint or ‘Don’t Care’ (represented by ‘%’)
  3. Our ‘action’ is simply to report the name of the rule that matched

So a typical decision table might look like this:

Name Condition 1 Condition 2 Condition 3
Rule A T T F
Rule B T % %
Rule C F T T

Conditions are “boiled down” to True or False for each message before they are fed into the decision table, so the decision table itself does not contain any logic about individual conditions. Or in other words, our decision table may know there is a condition called “Message has a valid sender reference”, which can be True or False, but it does not know that this condition was calculated by calling a stored procedure on an external reference data source.

The Problem

How do we ensure that there are no messages which match more than one rule? For example, the following message will match both Rule A and Rule B from the table above:

Condition 1 Condition 2 Condition 3
Message ABC T T F

There are several approaches to solving this problem:

Give Up
We accept there will be multiple matches, and work out a process for determining precedence. For example, we could use some or all of the following:

  1. Most specific rule wins (least wildcards)
  2. Left-most condition matches are more important
  3. Newest rule wins

Brute Force
We generate a message population of all possible conditions, and simply feed it into the decision table. For a domain with many conditions, this population can get very big. For more than 20 conditions, you’ll run out of rows in Excel 2010, and for 80 conditions, you’ll be looking at 280 messages, or 1,208,925,819,614,630,000,000,000 in long hand (1.2 septillion according to Wikipedia) .

Analytical
We test each new rule against every other rule, without reference to example trades.

We will explore some of these approaches in the next posts in this series.

Posted in Models, Routing Rules, Rule Engines | Tagged , , | 1 Comment

ISDA FpML Training Course – Notes

FpML Logo A member of the team attended one of ISDA’s London training session on FpML (the basic FpML Training Course, 26-Nov-2013).

 

The good?
+ Rather natty FpML 5 User Guide
+ Authoritative talk on interest rate derivatives from Harry McAllister (Information Architect, BNP Paribas)
+ Many pertinent heckles from Andrew Jacobs (FpML Lead Architect, HSBC, and proprietor of HandCoded Software)

The ‘room for improvement’?
– Time management – one 40 minute session overran by 50 minutes 🙁

What we learnt:
Most of our recent experience is with FpML 4 –  the message structure in 5 is looking a lot cleaner

We are working on product taxonomy and reference data at the moment, so the content around FpML coding schemes was highly relevant, as well as the insight into how the FpML authors decided whether to use enumerations or external coding schemes.

Always good to have XML namespaces explained again – we’ve looked at it for 15 years, and it never seems to get any easier to understand.

Posted in Derivatives Industry, FpML, ISDA, Messaging Standards, Trade Organisations | Tagged , | Comments Off on ISDA FpML Training Course – Notes

5 Things you need to know about Routing Rules

Here at Redhound, we have a wealth of experience of enterprise integration and messaging projects. Here we’ll share some more of that experience with you around the Routing Rule Engine (RRE). At the end of it, you’ll have a better feel about how to implement one, but if you’d like to chat about it, just get in touch.().


So, let’s get on with it…


The RRE is the fundamentally essential component of enterprise integration and messaging projects. Without a coherently designed RRE implementation, you’ll very quickly have a trade flow or other message driven wokflow process that’s out of control. Not so much peeking in to Pandora’s box as ripping the lid off, kicking it over and shaking the contents out.

1. Save money- think strategically
You may think that your workflow is a simple affair. It has a single point of entry for actors. The progression is linear. Data flows to core app A then core app B then core app C. Why would you waste time on a RRE implementation? The answer lies in the addage, “Hope for the best. Plan for the worst”. Spending time thinking about a strategic way forward for your domain and what issues you may encounter in the future is an invaluable investment.


How soon will it be before you have to start handling breaks in your flow? Or you are required to add another core app? Or a recs process? The moment you have to start thinking about that, then your original message plumbing needs to be redone. Not just during your development but in a BAU production appplication stack – that sounds like a blast. It’s the enterpise integration equivalent of laying a gas main to a housing development and then having to dig it up again to lay the electricity cables. In short, it’s very expensive both in money and reputation.

2. Support dual routing
Messaging flows in enterprise domains are more often than not devilishly complicated. The Nirvana of a linear data flow is very rarely seen. More often than not, your incoming actor message will need to be directed to more than one destination. Your incoming trade needs to go to the recs process as well as to the accounting function. Your routing rules need to be able to cater for that in the most efficient way possible. At first glance, it would make sense to have a routing rule for each destination:

  • Rule A with condition xyz is matched and the trade is despatched to the recs adapter
  • Rule B with condition xyz is matched and the trade is despatched to the accounting engine

This is a logical implementation of a problem solution. However, across multiple destination nodes and complex routing rulesets, the overhead added to the RRE is significant. Additionally, this implementation clouds the vital diagnostics that can be gleaned from maintaining statistics around which rules are fired and how often (discussed later).


By far the best way we’ve seen to implement these rules is to incorporate multiple routing options at rule level. This reduces the load on the RRE by separating the decision making from the resulting required actions. Our example routing rule would then look something like this:

  • Rule A with condition xyz is matched and the trade is despatched to this list of end points (recs, accounts)

This simple, yet powerful shift in thinking immediately halves the load on the RRE and makes working with the ruleset a much more manageable experience. It also makes testing the ruleset against your regression packs easier.

3. Embrace centralised rules
Most enterprise workflows require complex routing solutions. Actors can enter the flow at multiple points and there are routing decisions required at many waypoints. If you wish to save yourself a world of pain, bring your routing rules into a single, centralised solution. The problem with the label “Routing Rule Engines” is the “s” on the end. Your RRE should be developed and implemented as a central, visible service that is exposed to any waypoints that care to engage with it. Segregate your routing decisions on the rules themselves. For example, waypoint A will only be presented with those routing rules that are relevant to that waypoint. It doesn’t need to worry about segregation as this is inherent in the RRE service itself. Once again, this supports a distrubuted development and test project team and allows them to develop and test independantly. Additionally, the knowledge of what your data flow is, what it does and where it goes, can be seen in a single place.

4. Know your most popular rules
Without a doubt, the most powerful piece of MI that a RRE can produce is the break down of those rules that have been fired. This gives an immediate insight as to what is happening in your stack. Without out it, you need to rely on the core applications to provide this information. This means building out MI functions on numerous applications, in differing timezones, on differing platforms with all the associated expense in terms of both time and money that that would involve. When your MI is harvested at the core app level, the business context is lost. It is not possible to “re-tell” the story.

On numerous projects we have implemented rule firing MI on RRE solutions. Time and time again, it provides an holistic view of the business conversations that are taking place in your domain. It has even been possible to perform rules based data profiling activities and analyse data categories using this method.
The RRE is working hard for you – make the most of it and harvest the most MI you can from it.

5. Modelling tools
Modelling solutions are a particular speciality of ours at Redhound. If there’s a RRE involved in your solution then you’d better start modelling from the very start of your project. It will prove to be the best investment in time and effort you have ever made.

  • Want to understand how data is going to flow in your solution? Model it.
  • Want to see where your choke points are going to be? Model it.
  • Want to be able to work in an agile way, seeing results immediately? Model it.

You can model effectively in the MS toolkit with Excel and Access. This is a great place to start, but to gain the absolute maximum benefit from your model, think about getting it to hook into your evolving solution. Modelling routing rules and then washing your domain data against them with immediate results without having to open up your fledgling adapter framework is a liberating experience. Your model should deliver your tested rules, drive out your adapter framework, your mature static data requirements and your asynchronous framework.
For further information on modelling, see my previous article Business Analyst’s Tools – Data Flow Model

The above will give you some real pointers into the areas that you need to think about when working in enterprise integration and messaging systems. We’ve found them to be project savers time and time again. For a further, in depth chat about routing rules, messaging and integration, just drop us a line. One final thought for you – the only thing more expensive than a good routing rules specialist is a bad one.

()

Redhound are happy to advise on all aspects of business analysis modelling, including reference data, business process and trade flow.

Our live Cloud-based demo integrates a Eurex clearing feed into a trade flow with complex routing rules, and is a working example of our modelling techniques.

Get in touch!

We hope this post has been helpful.

If you’d like to find out more about our routing rule philosophy, how we do this and what it looks like, get in touch

Posted in Business Rules, Models, Routing Rules, Rule Engines, Uncategorized | Tagged , , , , , , , , , , , | Comments Off on 5 Things you need to know about Routing Rules

The Tyrant System


It’s time to name something in the enterprise integration landscape: the tyrant system.

The tyrant system is where your project dreams go to die. The tyrant system does not answer to anyone. The tyrant system has releases once in a blue moon, and the rest of the organisation had better make sure they fit in. If you don’t like the tyrant system’s API, you are welcome to spend months coding around it, but the tyrant system reserves the right to change and break your code without notice.

The tyrant system gets to say what operating system, what hardware and what other software it will work with. The tyrant system is invulnerable to external change driven by anything smaller than regulatory authorities¹. The tyrant system has a development plan that was set in concrete before you were born; if you want to be agile, knock yourself out.

The tyrant system is easy to spot. It uses 1970’s alphanumeric codes for business terms, and somehow everyone uses them (it is a rite of passage for new joiners to know what a “Z5R” order is). The support team have a web site explaining in great detail what the rules are for the business to get help (and how many months that’s likely to take). In a generally frenetic environment, calm pervades the tyrant system’s development area. There is absolutely no documentation. Recruiters hire for skills in the tyrant system specifically. No one ever explains a tyrant system requirement in business terms. You do it because the tyrant system says it must be done.

There is nothing necessarily wrong with one system to wielding power over others. If you own a business, you want the system closest to the people making money to get highest priority. You have a tyrant when the system calling the shots has nothing to do with that. History offers little comfort. The ruinous reign of a tyrant can last for for decades, and power is never ceded voluntarily. The only hope for us is that, in the very long run, change is inevitable. And perhaps we can also take comfort from the motto of Virginia – sic temper tyrannis!

¹ Assuming your country’s GDP exceeds that of the tyrant system vendor

Posted in Enterprise Integration, Project Management, Vendors | Tagged , | Comments Off on The Tyrant System

Rogue Trading for Dummies Part 1 – Using Trade Booking to Beat Risk

Have you ever given any deep thought as to how rogue traders manage to get away with their activities for so long? In a trading landscape driven by technology, it should be impossible to get up to anything like rogue trading, shouldn’t it? Well, as we’ve seen in the recent press, it is still possible to get away with it, at least for a while, either until the rogue trader can’t hide it anymore or he brings down your firm. Both outcomes are unpleasant, to say the least.

In this series of articles, we’ll explore one of the shadows where rogue traders hide – behind poor trade booking practices and weak or ineffective policy enforcement. Firms that operate in this way also have to contend with the other two sides of the “I’ve lost control of my bank” triangle, namely poor risk management and inaccurate regulatory reporting. ().

So, let’s have a look at why booking policies and enforcement are critical to a firm’s health, where the pain is felt without them and where your rogue trader could be hiding.

Since the severe problems encountered in the financial markets four years ago, government agencies across the globe have accelerated the imposition of increasingly risk averse regulatory reporting frameworks. This has come at a time when firms are still dealing with continually turbulent market conditions and the need to continue to make a profit. It has never been more important to know the risks that your firm is exposed to, to manage them effectively and report upon them diligently whilst still looking to maximise the firm’s assets and resources in the pursuit of that healthy profit.

The question is how do you do this? How do you know what your current risk level is? There are a plethora of risk management systems and strategies in place throughout the industry that will give a clear indication of the risk that the firm is carrying and this supports strategic decision making processes. Obviously, all these systems rely on accurate data in order to ensure that the picture they paint is correct and reflects what’s happening on the shop floor. So the question is, how accurate is the data the flows into your risk management and regulatory reporting processes?

The true answer, no matter how unpalatable it may be, is that years of “just get it done” attitudes to business, system and data challenges has more than likely left you with an inventory of data that, although at first glance may look OK, is in fact misreporting your risk, failing to meet your regulatory requirements, preventing you from leveraging your positions and trading limits to generate more profit and, potentially at the same time, hiding your rogue trader.

To illustrate the point, let’s look at trader A working on a flow rates desk. As well as booking swaps on the Interest Rate Swap template, he has been booking fees on the same Interest Rate Swap template for the past three years, because this is the only way he can get these into the system. Technically, fees should be booked in a different front end system right across the firm. However, neither trader A, nor his extended team, has access to that system. This approach was the result of a poor tactical decision taken in order to expedite the processing of fees on this desk three years ago. The reasons for the decision have now been lost in the sands of time but it works “OK”. Trader A can book his fees and the money pops out at the other end so all must be well.

Unfortunately, this decision was taken without assessing the full impact of the approach and what it would mean to the middle and back office. It turns out that “OK” actually generates significant breaks in the middle office as these fees will not achieve straight through processing. They require manual intervention in order to process them. Additionally, both finance and settlement IT have had to build out and implement tactical fixes at the boundaries of their applications (accounting rules engine and data load and mapping respectively) in order to handle them. These changes have been designed, developed and implemented independantly. They have been built out on different technology platforms by different teams in different time zones. They have been “squeezed” into a heavy book of tactical work in these domains. All three areas:

• are being impacted by poor booking practices in the front office

• have to react to due to a failure to use the correct system for these fees

• are experiencing a daily, ongoing and never ending waste of effort and cash.

Additionally, this poor booking practice (the “fudging” these fees into the trade capture system) has the effect of clouding the firm’s understanding of its true exposure whilst simultaneously impacting its ability to satisfy regulatory reporting requirements.

So it is clear that a tactical decision made years ago, in a pressured situation has resulted in a negative impact on at least three downstream cost centres and may also be causing the bank to submit inaccurate regulatory reporting to the FSA and other regulatory organisations. Given how easily this decision appears to have been made, it is more than likely that many other such tactical decisions have been made across the firm, resulting in other potentially more unpleasant issues in risk and reporting.

Let’s also not forget that this activity could be counting negatively towards trader A’s trading limits. He could potentially be doing significantly more Interest Rate Swap trades. He could be making a healthier profit for the firm. But he can’t as his limits prevent him from doing more than he is, even though a good percentage of his “trades” are actually fees.

All the above problems are a drain on the firm’s resources and have a real cost implication. A “tactical fix” here and a “quick win” there can have major impacts downstream to cost and effort:

The final, logical and disturbing conclusion from tactical decisions that generate tactical system fixes to accommodate them is that these leave the firm open to exploitation. If a trader is aware of the tactical downstream “fixes” that have been implemented in order to deal with poor booking practices, it is not inconceivable that there lies a “window of opportunity” between these tactical patches that could be exploited to hide rogue trading activity. Processes that exclude a trade, because it is deemed to be a tactical fee booking, in order to protect a reconciliation process presents a rogue trader with the opportunity to manipulate this “patchy” control landscape. With the court proceedings currently underway against alleged rogue traders, it is clear that this danger is always present and systems and processes that allow themselves to be “played” only go to encourage this activity.

So, what can be done about this issue? Where do you even start to determine if your data is correct? How do you determine where tactical solutions have impacted on your risk and reporting processes? Over the next few articles, I’ll explore the options available, how they can be implemented and where potential downfalls may hide.

NEXT article: Rogue Trading for Dummies Part 2 – How to waste money on Risk systems

()

Redhound are happy to advise on all aspects of business analysis modelling, including reference data, business process and trade flow.

Our live Cloud-based demo integrates a Eurex clearing feed into a trade flow with complex routing rules, and is a working example of our modelling techniques.

Get in touch!

We hope this post has been helpful.

If you’d like to find out more about our business rule philosophy, how we do this and what it looks like, get in touch

Posted in Booking Practice, Risk Management, Rogue Trader | Tagged , , , , , , , , , , , | Comments Off on Rogue Trading for Dummies Part 1 – Using Trade Booking to Beat Risk

10 Questions To Ask About An API

The presence of an API in the systems we were buying or building used to be a nice feature to have. It would be appreciated by those trying to write management reports, but it would not be foremost in the minds of those making the business decisions.

Today, the API is coming to the foreground. We build our technology solutions out of a mixture of hosted services, vendor systems and inhouse development, and the ability to connect these systems together painlessly is becoming important.  Ask the questions below before you sign off.

1. Is the API documentation publically available?
Assuming there is any documentation at all, this is usually a good measure of how mature an API is. If a technologist is ready to publish their interface to the world, this shows confidence that the interface works, and that they are trying to encourage people to use it. If the API documentation is hidden behind partner logins and NDAs, this shows the supplier aniticpates a higher level of handholding and explanation. Which means more work on your part.

2. Does the API documentation cover messages/methods, fields and values?
API documentation should minimally tell you what messages you can send / methods you can call. Better if each field is described. Best if the allowed values and constraints in each field are  enumerated. There is a special circle of hell reserved for people who write things like “systemGUID: use this field to specify the system GUID.”

3. Does the API documentation cover error cases / codes?
Often neglected in API documentation are the error cases and error codes. I’ve never seen this done perfectly, but a list of numeric codes with explanations of likely causes and remedies is always welcome.

4. Is there an SDK?
The presence of an SDK is another sign of maturity, along with public documentation. A lot depends on the quality here, and you’ll probably have to load it up and spend a few hours using it to find out. Any SDK purporting to be .NET should work in the latest version of Visual Studio without making you jump through project upgrade hoops. Can you make a basic call to the remote API? Is there a test account present for specifically this evaluation purpose? What you are looking for is saving time, and if you’re left feeling “maybe it would be easier to go straight to the database / web services, everyone’s time is being wasted here.

5. Are there end-to-end working code samples?
Although there are a few stateless APIs, most follow the pattern below:
a. Make an authentication request
b. Receive some kind of secret key
c. Make your business requests using the key
d. Sign off

The business request itself may be broken into more than one stage – for instance, if you are updating a contact in a CRM system, you may first need to search for and retrieve an API reference for the contact before being able to udpate it.

So all of this adds up to you having to make a *sequence* of linked calls, which in turn means having some full examples showing you how to do this. But even though it sounds important, most API documentation won’t show them. If you’re lucky, there’s an out-of-date SDK, but chances are you’ll have to phone the company in question.

6. What technology choices does the API support?
This is just a straight question, and depends on your requirements. A SOAP or REST interface is the standard, and will give you plenty of modern choices. Although Amazon Web Services is an interesting example of an API that is ostensibly open (REST), but complex to use, so you are effectively tied to whatever platform you can get an SDK for. (I only know this because I investigated what would be involved in creating an MD5-signed request to AWS in VBA – mon dieu!)

7. Does the API give you a receipt?
Any API should give you some kind of reference to any objects you create or update, and don’t under any circumstances touch one that doesn’t. Better still, you ought to be able to pass in your own reference. The receipt or reference becomes crucial as soon as you want to ’round trip’ an API call. If you don’t get one, you are left with a nasty correlation problem, and end up trying to guess which output record from the API corresponds to your input record.

Whether it’s your own reference, or a system-generated one, make sure you also understand how long those references are good for, and also that you’ve sufficient capacity for your own purposes. (In a trade flow where you might be passing millions of records a day, a ten or thirteen character field is not going to give you much room for comfort.)

8. How is the API metered/throttled?
Per-request is the most common, but you’ll also see bandwidth and storage with modern cloud services. Be very wary of any APIs that are metered per-user, or by the number of simulataneous connections. It’s not that there’s anything *theoretically* wrong with these things, it’s just that if either you or the API-provider don’t clean up old connections properly, you’ll get locked out, which is annoying and hard to debug. I’ve encountered this on two different APIs, and it just makes you want to kill the vendor.

9. Does the API allow reference data updates?
As the systems you target get bigger and bigger, reference data becomes more and more of a challenge, especially when you are integrating System A to System B, rather than User A to System B. You can make User A re-enter information they’ve already entered elsewhere or manually correlate new records to identifiers in System B (as anyone who’s tried to open a new savings account with their bank can attest), but System A and System B are going to need a more resilient method. For a given entity, System A must know System B’s identifier, or how System B correlates to that entity, otherwise you are going to lose referential integrity. In the ideal world, reference entities are managed in one place, and this ‘golden source’ propagates changes to downstream systems throughout the enterprise. If you ever meet anyone who thinks this sounds easy, ask them if they have a global canonical source of country names*.
10. Does the API support asynchronous calls, and if so, how?
For long running transactions, we may well need to tell an API to do something, and then come back some time later to check the results. One way of accomplishing this is with a ‘polling’ architecture. So we make our request, and we are then responsible for monitoring a message queue or a database table for notification of the result. The alternative architecture is to pass in a custom callback on the request side, so that the API itself can call a function when processing is complete. A well known example of this is  PayPal, where you pass them a URL they can ‘ping’ when a payment is completed.

In summary, these are all good questions to ask when evaluating an API. Since the exercise of selecting an API usually happens as part of a wider technology decision, you might not get much time to ask them, or to do much about the answers. Inside that context, I’d focus just on the correlation question. It is a fundamental requirement, and coding around a poor or lazy solution is painful and frustrating.

*Don’t ask this in America. A list of US states and ‘Rest of World’ is not the right answer.

Posted in API, Architecture, Enterprise Integration | Tagged , , | Comments Off on 10 Questions To Ask About An API

Business Rules and Engines

This topic expands on my previous post “Increasing STP Rates – the Fantastic Four“. Specifically, I’m going to expand on the role of the centralised Rules Engine, what it does and how to use it. ().

You’ll no doubt have heard about these before and have perhaps even worked with something like Drools or the Wolf Framework. I’m not going to deliberate the best technology stack here, the best choice for you in that regard will have a lot to do with your current stack, your ability to support that stack and your appetite for 3rd party solutions. Instead, I want to hone in on business rules, how you can classify them and how you can look to implement them.

Our experience has taught us that rules generally fall into a number of predefined classifications:

  • Data handling (completeness, transformation and mapping)
  • Enrichment (internal domain information, allocation, matching)
  • Filtering (inclusion and exclusion)
  • Sequencing (expected order, missing messages, duplication and replay/resubmission)
  • Validation (successes and breaks)
  • Routing (single/multiple destinations, re-routing, replay)

All of these classifications present their own specific challenges. Their correct application is critical to the success of enterprise messaging solutions (our speciality). Regardless of whether you are working on a green-field project or replacing an existing spaghetti middle/back office solution, you need to elicit and classify your business rules correctly.

Let’s run through the classifications and see the challenges that each presents.

Data handling & Enrichment
All messaging systems need to implement these rules. You need to ensure that the message you are processing is correct both syntactically and symantically. Does it conform to your XML schema? Are the required data items present for this business case? Can you consistently map the incoming message format to your domain language? Can you enrich your data to simplify downstream processing?

Ideally, these business rules need to be performed as early as possible – at your system boundary. If you allow malformed and incomplete messages onto your bus via your routing rules, your downstream consumers with feel the pain, your problems will grow expotencially and your costs will increase significantly. Advising your Operations Managers that they will need to throw bodies into the middle office to manually resolve data problems is not a viable career development strategy.

Filtering & Sequencing
Often, your system will be presented with message that are out of sequence, duplicated or that your system does not need to process. Perhaps worse is the scenario where you are not presented with messages that you expect to receive.

You need to understand the conversations that take place in your incoming messages. Do you just receive and process unique, isolated messages or do your messages convey business meaning through a chain and sequence (new booking, reversal, shaped adjustments etc).

Filtering rules will protect your system from data that it isn’t required to process. Sequencing rules will identify missing, out of sequence messages and intelligently manage them until the missing messages arrive and the sequence can be played correctly or until such time as they decide that this is not going to happen and alerts need to be raised.

Validation & Routing
Your rules need to be able to specify the action to be taken upon a successful or unsuccessful outcome. If this message has been handled and enriched; filtered and sequenced and all is well, what do you do with it then? Where does it need to go? Does it need to go to more than one place? What if it has broken one of these rules? What happens next?

The big challenge facing business rules and the rules engines they operate in is that, more often than not, several business rules relating to a single incoming message will be identified. In order to process the message successfully, these rules need to be applied in the correct priority sequence so that business meaning can be achieved. If the first rule fails, then the rules engine will move onto the next rule and will keep going until a match rule has been found. However, be watchful for distinct subsets in these rules that require a hard failure only halfway through the rule stack. Your rules engine must be able to handle this scenario.

 

Whichever way you decide to implement business rules, the above will be invaluable to achieving success in your project. Before I finish, here are just a few parting shots – make sure that:

  • Your business rules are reusable
  • Your rules engine can access external data
  • You have adequate logging
  • You have automated regression testing packs that can verify rule changes quickly
  • You have sufficient granularity in your rules (client/product specific)
  • You have adequate versioning and documentation of your business rule sets

There, I think that just about does it. Business rules are a fantastic direction to take your project in. Just be very careful about how you approach designing and implementing them. And remember, the only thing more expensive than a good rules business analyst is a bad one.

()

Redhound are happy to advise on all aspects of business analysis modelling, including reference data, business process and trade flow.

Our live Cloud-based demo integrates a Eurex clearing feed into a trade flow with complex routing rules, and is a working example of our modelling techniques.

Get in touch!

We hope this post has been helpful.

If you’d like to find out more about our business rule philosophy, how we do this and what it looks like, get in touch

Posted in Business Rules | Tagged , , , , , , , , , , , , , | Comments Off on Business Rules and Engines

Business Analyst’s Tools – Data Flow Model

In this article, I’m going to talk about a simple yet powerful tool that every Business Analyst should have in their arsenal – namely Data Flow Modelling (). Specifically, I’m going to talk about producing a tangible asset that can be prodded and poked by the BA team, the development team and even business users in order to gain a clearer understanding of the Target Object Model. I’ve used this approach on numerous occasions, and it is particularly useful in trade flow projects.

Models can take lots of different forms. These range from the vapour model in your stakeholder’s mind to the stack of exquisite UML Use Cases and Sequence Diagrams in your design specification. But the gold standard is a working model that performs processes, uses reference data, makes decisions on a critical subset of data objects and shows a use case being processed through the Target Object Model. We produced one of these on a recent derivatives clearing messaging project, and I’ll use that as an example.

The steps we followed can be summarised as:


Producing the Trade Flow Playlist

The first thing we did was generate a “Play List” of the possible paths our trades could follow through the trade flow. We employed highly sophisticated tools  – some Magic Whiteboard and a stack of Post-it Notes. We drew our messaging domain on the Magic Whiteboard, and then marked out our inputs, our proposed messaging queues and our endpoints (effectively our middle office core applications). We used the Post-it Notes to represent our actors (trades coming from the exchange) and walked through the processing of each message, noting the waypoints they went through, when they got there and what supporting data objects each message required at each of these waypoints.

We were particularly keen to understand how, where and under which circumstances a single actor being input to a waypoint resulted in two actors being output on different message queues. All this was documented on more Magic Whiteboard and used to drive the next process in our model development.

Visualising Use Cases in Visio

At this point, we felt pretty pleased with ourselves. Despite having dry wipe marker on our hands and dirty shirtsleeves, we had a set of scenarios and enough detail to start producing our use cases. We broke out Visio and translated our play lists into use cases, showing the processes our actors would flow through and the data and success/exception/constraints that they would be subjected to. This process gave us our bible of use cases and they were built in such a way as to provide “snap shots” in the life of each actor. These made a useful tool in their own right (having a full set of use cases is important to all projects), and this process also highlighted commonality within some of the processes – allowing specific use cases to be developed for them in their own right (our  being a prime example).

Given the very complex Target Object Model, and the effort required so far in understanding the flow and how it would work in real-time, we wanted something more tangible – something we could run our use cases through and iron out issues, drive out data problems and “taste” the effects of our proposed asynchronous messaging design.

Bringing it alive with Excel Models

In order to get a living breathing model, we decided to build it out in Excel. We produced a brief that required us to visualise the message queues and core applications as tabs in the spreadsheet and our use case actors (trade messages) as individual rows on these sheets. Our model would initially use additional tabs to hold the routing rules and reference data required to support the processing of our trade messages by VBA code. Our messages would move from tab to tab mirroring the processing flow in our use cases.

This proved to be a fast process and was handled solely within the BA team – without the need to disturb the developers. Whilst building this, we were forced to revisit our use cases several times in order to review the flow in various places and we could also see how our reference data requirements were maturing. To further enhance the model, we broke out the tabs containing our reference and routing rule data to MS Access and changed the Excel model to use that for its data requirements.

All this effort gave us the ability to run our use cases through the model (simple trade; simple trade with reversal and rebook; simple trade with give up etc). We could clearly see where we had issues around how we accessed our reference data and processed it. It was a superb model and it allowed us to walk through scenarios with the business and to bring the development team up to speed with what the Target Object Model actually looked like, how it processed, where data bolted in and what sort of things they needed to think about when designing their Adapter Framework.

There was only one thing missing from the model. This was the ability to asynchronously process all messages on all queues at the same time – just as our proposed Target Object Model would require. What problems would we encounter when we started pushing our use cases through the system? Could we really afford to wait until the integration testing phase until we discovered these problems? We didn’t know, and couldn’t wait, so we moved to the Cloud.

To the Cloud – Asynchronous Trade Flow Model in PHP/MySQL

We built out a Cloud-based version of our model, making use of all the information and knowledge we had acquired to date in the production of our play list, use cases and Excel models. For the technically minded amongst you, it was built using a PHP Framework and made use of a simple MySQL database backend. It was a relatively fast process to go through and we had something up and running within a couple of weeks.

We were able to drop messages (actors) into the Cloud model, see our Adapter Framework engage with those use cases and watch them flow through the message queues and into the core applications in our Target Object Model.

The model quickly highlighted the race conditions that we would encounter in our proposed system. It showed that our use cases needed to be expanded to include a “trade state” use case that applied business rules to the order in which status updates should be applied in the Target Object Model. It allowed us to see the issues around breaks and how resubmission would impact on the message queues. Finally, it provided a convenient hook for our test team to hang their test cases off, and prompted them to develop automated tools that would support integration testing, UAT and issue management.

Summary

All these steps gave the project knowledge:

  • Requirements capture and use cases were correct
  • The reference data model was mature
  • Asynchronous processing would not go into “melt down” at a business rule level
  • Appropriate test tools were built and made available for integration testing and UAT
  • The project had a tangible model of the Target Object Model for future projects in that domain

Not a bad result for a BA team to deliver to its colleagues! ()

Redhound are happy to advise on all aspects of business analysis modelling, including reference data, business process and trade flow.

Our live Cloud-based demo integrates a Eurex clearing feed into a trade flow with complex routing rules, and is a working example of our modelling techniques.

Get in touch!

Ben has already written extensively about Adapter Frameworks as part of his “10 Things You’ll Do On Every Message Project” series.

Give us a shout if you’d like us to help you create one of these, or to review your existing one.

We hope this post has been helpful.

If you’d like to find out more about our data modelling philosophy, how we do this and what it looks like, get in touch

Posted in Data Flow, Domain Model, Models, Trade Flow | Tagged , , , , , , , , , , , , , , , , , | 2 Comments

10 Things You’ll Do On Every Messaging Project – Designing an Adapter Framework

This is the second in our series on life on an enteprise messaging project. This time we will be discussing that adapter framework you noticed appearing in the development team’s conversations. There’s no line for it on the project plan, and the client is *definitely* not going to want to pay for it.

DISCLAIMER Nothing in this article should be taken as a inducement or encouragement to engage in enterprise architecture unless supervised by a fully-qualified adult. The only thing more expensive than a good enterprise architect is a bad one.

What are adapters?

Shows System A feeding a message queue feeding System B

Adapters are the integration components that connect your messaging software to your core systems. You will have two basic types:
– ‘Outbound’ adapters: These poll your core systems for changes, and convert these changes into messages which they push to the messaging software. E.g. you might watch a SQL table and convert new records into a message
– ‘Inbound’ adapters: These poll a message queue for new messages, and convert these messages into API calls to a core system (assuming you’re lucky enough to have an API – the default one is called ‘stored procedure’)

What are adapter frameworks?

Adapter frameworks turn up as soon as you realise you are going to be creating quite a few adapters in your architecture. There are lots of things that ALL of your adapters will be doing, so it makes sense to solve these problems once, and then share these common solutions across all adapters. The rest of this article is about how long that list can get.

Logging and Error Handling

You can never have enough logging in a software system that doens’t have a GUI. You want to make it *really* easy for adapter developers to send frequent and verbose messages to the logging layer. You want log messages to include things like time, date and machine name automatically. If you allow multiple instances of the same adapter, you also need to correlate log messages to a particular instance. You might also consider rolling your log messages up to a single location, then you can get a unified view.

Error handling starts with logging – but you then should think about some general error handling strategies that you wish adapter developers to adopt. You should have a common set of negative unit tests that all adapters should pass:
– queueing system is down
– core system is down
– adapter host is out of disk space / memory
– poison message

Screen capture of Null Pointer Exception

You should also consider sanitising any messages that either support staff or end users will encounter. This could be addressed by a  as much as a code library.

Architecture

Unless you have a particular reason to allow cross-platform adapter development, you will want adapter code as either Java libraries or .NET assemblies, which in turn implies development languages, run-times and operating systems. Both are safe choices – any core system you encounter will probably have:
(a) A binary SDK for both platforms -or-
(b) A platform-netural API that both platforms support (e.g. SOAP, ODBC)

There are many standards that are relevant to the messaging world:
AQMP for messaging
JMX or SNMP to allow your adapters to report status
WCF as an adapter accelerator if you are using .NET
Common Logging
Quartz for adapter poll schedules

As ever, it is more important that you have standards than the particular standard you select.

You should consider at what level different adapter instances share resources. Any combination of the following strategies are possible
– multi-threading inside a single adapter instance
– multiple adapter instances inside a single container (an example of a container would be Tomcat in the Java world)
– multiple containers inside a single run-time (either the .NET run-time or the Java run-time)
– multiple run-times on the same machine

These choices have an impact on manageability and thus your support department. A lot of support and monitoring software is targeted at the machine level, so you might think you are saving money on virtual machine instances by running multiple adapters on single nodes, but you are certainly going to be spending some money replicating or modifying systems like Hyperic.

Adapter Management

On larger projects, you will find that the challenge of configuring, deploying, versioning, controlling and monitoring adapters looms large. It makes sense to centralise as many of these functions as possible. Your adapters will need to be self-describing, and will ideally be discoverable to management systems, rather than needing to be explicitly registered.

There will be some configuration differences between an adapter polling a queue and an adapter pushing records into an SQL database, but these differences should be a matter of different fields being present, rather than requiring radically different administration procedures. Thanks to the  , configuration settings will always include both a description and examples of valid values, so that it is easy for support teams to pick up what is going on with a new piece of software.

Adapter Business Logic

While your development team are building your adapter framework, your business analysts will be busy analysing and defining the actual messages that will shortly be winging their way through your adapters. Most analysts will present these specifications in either Excel or Visio (if you are lucky), but the foward-thinking architect may wish to consider embedding an ETL design tool such as Volante into the adapter framework. That way, specifications can be created directly in the GUI, and can be exported back into documentation at any point when paperwork is unavoidable. You may not be able to persuade your analysts to touch these tools, but they will certainly be a godsend to the development team.

You will also find that some message types are taken in and out of adapters in multiple places, particularly if you are thinking ahead and using a standard such as FIX. So you should also consider sharing your ‘message library’ across adapters. That way, updates can be applied consistently, or mistakes can be fixed in just one place (depending on how jaded you’re getting by now.)

Conclusion

With all this work going into the adapter framework, you’d be forgiven for wondering if this isn’t where most of the actual effort goes, and you’d be right. You’re actually creating an application template that may get used 10 or a 100 times through your project. But if you get it right, you’ll be creating and deploying new adapter instances in matter of weeks.

Give us a shout if you’d like us to help you create one of these, or to review your existing one.
Give us a shout if you’d like us to help you create one of these, or to review your existing one.
Posted in Architecture, Business Rules, Data Mapping, Domain Model, Enterprise Integration, Message Queue Software, Messaging | Tagged , , , , , | 2 Comments