In the 1968 hit comedy, Take the Money and Run, Woody Allen tries to rob a bank by handing the teller a note that says, “Give me your money. I have a gun.” The problem is, the teller can’t read his writing, and thinks the note says, “I have a gub.” The teller asks Woody Allen to have a bank executive initial the note before he can complete his robbery. All joking aside, though, this scene offers a great take on the difficulties that banks face in developing and enforcing sound security rules that can weather the tension between large bureaucratic enterprises and rapidly changing business conditions. In the area of anti–money laundering, which has become a serious area of concern in the age of terrorism, banks are under more pressure than ever to find effective and low-cost solutions to this pervasive crime.
Money laundering is the cash register at the end of a myriad of criminal processes—it’s how crooks bank their ill-gotten cash and make it look like legitimate income. The Wall Street Journal, citing a KPMG study, estimates that money laundering is a trillion dollar crime worldwide.1 In this chapter, we take a look at the problem of money laundering, and the ways that banks approach combating it. In particular, we dig into the information technology aspects of the anti–money laundering solution, and suggest ways that event-driven architecture (EDA) can help in the fight.
An SOA-based EDA, with its ability to gather data from disparate sources in a rapid cycle, has the potential to power effective and dynamic anti–money laundering detection. In this chapter, we explore the ways in which EDA can make this happen, with emphasis on EDA’s potential to drive business rules processing and internal controls of both the detective and preventive nature. We also revisit the idea of “carrying state” in transaction messages as well as the organizational aspects of such an ambitious program.
Seeing EDA as a key part of a solution to a very pressing and complicated problem
Understanding how EDA can facilitate the enforcement of business rules that need to change continually to keep up with sophisticated criminals
Seeing the potential for EDA to help international multithreaded compliance
Understanding how EDA connects with the implementation of internal controls, both detective and preventive, as well as continuous monitoring and auditing
Understanding the governance issues inherent in a complex, multistakeholder EDA
Money laundering is the act of hiding illegally earned money from the police or tax authorities by making the illicit funds appear as if they originated from legitimate business activity. Typically committed with the unwitting assistance of a bank, money laundering is usually the final step in the commission of some other crime. Money laundering is a necessity for criminals because they need to have some way of explaining the source of their income to police or tax officials who might see financial assets as evidence of criminal activity.
For example, in the movie, The Godfather, Don Corleone starts an olive oil business to mask his criminal empire. Whatever money he earns, he tells anyone who wants to know, comes from his olive oil business, GencoPura. Of course, the olive oil business does not generate the income to support Don’s lavish lifestyle. Instead, Don Corleone places his illegally earned money into the olive oil business’s bank accounts, where he “launders” it and makes it look like legitimate income. Don Corleone, in addition to being a mobster, is also a money launderer. Let’s take a look at how Don Corleone might launder his funds today.
Money laundering is a three-step process that is designed to evade many types of detection. At the government level, money laundering needs to mask criminal activity from law enforcement. At the bank transaction level, money laundering needs to slip under the noses of a variety of regulations and controls that are meant to ferret out such activity. The money launderer can get caught in either trap, so each step of the laundering process is carefully performed to evade detection.
The first step in a common money-laundering scenario leveraging bank deposit services is known as “placement,” where illicit funds are deposited in a business bank account. If one makes a cash bank deposit greater than $10,000, the bank is required to report the transaction to the government. Why? Because it is suspicious activity, especially if the depositor repeats the behavior many times. For this reason, money launderers typically have to place deposits in chunks of less than $10,000. Or, they have to figure out other ways to place the money into the business bank account. Don Corleone could have his bookkeeper write a bogus invoice for a cash purchase of olive oil, book the transaction as a “sale,” and then deposit the cash into the GencoPura bank account. Thus, he would have placed the illicit funds.
The next step is called “layering,” wherein funds are moved from bank to bank, and consolidated. This masks the trail of funds, and makes it hard to detect patterns of criminal activity. In some cases, layering is accomplished by the extending of bogus loans to offshore entities that will never repay the funds.
Finally, in the “integration” step, the funds are reintroduced to the financial system. For example, when Don Corleone writes himself a paycheck from GencoPura, where he has placed and layered illicit funds, he is paying himself with “clean money,” which he has successfully laundered.
There are many variations on these three steps, but the intent is always the same: masking the origin of illegal funds from criminal activity. One pattern that we focus on in this chapter is the phenomenon of loan repayment as a laundering technique. In this pattern, the money launderer takes a loan to purchase an asset, such as a car. Then, he uses illegal cash to pay off the car loan and then sells the car to a used car dealer. The check he receives from the used car dealer is his clean money that he can report as legitimate income.
The Wall Street Journal article mentioned previously also references a UK government study, published in February 2007, that describes how al-Qaeda money “...Can be raised in one country, used for training in a second, for procurement in a third, and for terrorist acts in a fourth region.”2 Think about that. Not only is money laundering estimated to be a trillion-dollar crime annually, but it also enables vast criminal and terrorist operations.
To put it another way, we want to share with you a conversation we had some years back with a prominent figure in the national security establishment. This man, who had been a highly decorated combat veteran in Vietnam, said, “You have to go after terrorists the way you go after guerillas... you have to hit them where they take refuge. And for terrorists, their refuge is the international banking system.”
From a societal perspective, as well as a legal one, there is a strong incentive to fight money laundering. The easier it is to launder money, the more crime can “pay.” With the terrorist dimension, lives are at risk. The risks of not detecting, preventing, and prosecuting money laundering are extreme, with far-reaching implications for the institutions that are unwittingly involved in the process. This is particularly urgent for banks.
Banks face multiple levels of risk from money laundering. They have direct financial risk, in the form of fines, penalties, and liability from accidental involvement in money laundering. If a bank employee is actually involved in aiding money laundering, these risks are greater. The bank also faces risk to its image if it is portrayed as being involved with crime, even if the involvement is unintentional.
As an example of how serious and real this risk can be, Marianne Pearl, widow of slain reporter Daniel Pearl, sued Habib Bank, Pakistan’s largest bank, in July of 2007, blaming them for the torture and murder of her husband in 2002. Specifically, her lawsuit alleges that a charity, the al-Rashid Trust, which banked with Habib Bank, was a front for al-Qaeda. And, the suit says that terrorists, backed by the bank, “...carried out the kidnapping, ransom, torture, execution, and dismemberment of Daniel Pearl and broadcast those images worldwide.”3 The coverage of the lawsuit also notes that U.S. regulators had announced earlier in 2007 that the bank had agreed to bolster policies aimed at detecting abuses by terrorist financiers, money launderers, and other criminals.4
To be clear, this is not a problem limited to banks that operate in countries that are under tight scrutiny for terrorism. There are undoubtedly other banks that have relationships with Habib and could easily be implicated in this kind of investigation. And as we know, money laundering is a global crime that affects banks in virtually every country. The risk, as you might imagine, is that the bank you work for could be traumatized by a criminal investigation, or even just the suspicion of the crime. Habib Bank might be completely innocent of the charges, but for many it will be viewed as the “terrorist’s bank” for years to come.
On a financial level, banks face numerous levels of risk from money laundering. If they are guilty of participating in money laundering, the banks face fines and penalties. They might have liability to crime victims and tax consequences. These kinds of improprieties can trigger shareholder lawsuits and bank regulator and SEC investigations. There might even be criminal defense costs to bear if bank employees knowingly committed crimes. And, there is the financial cost of damage to the bank’s reputation.
To mitigate these risks, banks engage in a costly set of controls and countermeasures, many of which are intended to comply with the substantial body of regulatory laws that govern the banking industry. These costs are rising, too, as the money-laundering problem grows more severe and global in scope. The KPMG study estimates that anti–money laundering compliance costs rose 60% from 2006 to 2007.
Unfortunately, even these added outlays for compliance and controls haven’t really made much difference in money laundering, though perhaps they have kept the problem from getting even worse. The core problem for banks is to find a way to comply with regulations and enforce controls that span multiple national jurisdictions. Anti–money laundering is a matter of global multithreaded compliance. Banks must be able to detect and prevent criminal money-laundering schemes that could begin with placement in one country, layering in another, and integration in a third. There are solutions to these challenges, but most of them come with high price tags and tactics that can strangle innovation and agility.
As we think about how anti–money laundering works at a bank, let’s consider some of the obvious internal controls. Without taking an unnecessarily deep dive into this fairly arcane accounting subject, we can grasp the intent and practical aspects of internal controls. If you run a bank, or any business, for that matter, you have a strong interest in knowing exactly how much money you are making, how much you have, and what your financial obligations are. The basic test of how well you have done at this process is to examine your financial statements for accuracy and integrity. If your income statement says you earned a million dollars, you should be able to verify that you indeed earned that million and that actual currency equaling a million bucks was put in the bank. Getting there involves designing and implementing processes, procedures, and rules—also known as internal controls—that govern the financial aspects of your business.
When you work with a bank, you participate in their internal controls on many levels. For instance, when you present your ID to cash a check or require a bank officer’s signature to receive a large cash withdrawal, you are working with the bank to control that no one other than you is withdrawing funds from your account. The bank invented these controls to keep you happy and prevent liabilities for themselves. (For those of you who love compliance, be aware that internal controls are at the heart of the much-maligned Sarbanes-Oxley Act.) Anti–money laundering is largely a matter of designing, implementing, and auditing internal controls that prevent and detect this crime.
There are two types of internal controls. A preventive control stops an infraction of the rules from occurring. A cash register lock is a simple example of a preventive control. The lock prevents an unauthorized person from opening the cash drawer. A detective control is one that an auditor or manager can use to look back at transactions and detect if an infraction of the rules took place. The cash register tape, which summarizes the day’s cash transactions, is a detective control. If the day’s total does not match the cash found in the drawer, the detective control will trigger an inquiry into why the two amounts do not match. If the detective control is well designed, it will also help identify the transactions and people who are responsible for the discrepancy.
Combating money laundering involves many preventive and detective controls. For example, to prevent money laundering, banks obey a federal law that requires depositors of more than $10,000 in cash to fill out a form disclosing the deposit. This law is both a preventive and detective control. By adding a governmental gate to large cash deposits, it deters money laundering. By creating a record of the names of large cash depositors, it helps detect money laundering.
The $10,000 disclosure law is a good illustration of how complying with a law creates an extended set of rules and business processes for a bank. As you could imagine, determined money launderers will find ways to get around this rule, so the internal controls must be good enough to catch money launderers who are too clever to deposit $9,999.99 every day at the same bank branch, and even that practice could evade detection if there were no internal controls or laws in place. How do you catch a crook who has ten associates depositing random amounts of cash ranging from $5,000 to $10,000 in ten different branches under ten different business names? That’s where this gets interesting, and that’s when it becomes an information technology problem.
Catching bad guys who use banks to launder money is a very tricky business, and one that is constantly changing. The most effective campaigns against this crime involve multiple levels of risk mitigation, including internal controls, training, cooperation with law enforcement, and communication with other banks. The most central feature of all these efforts, though, is the concept of business rules. Preventive controls require business rules, such as requiring disclosure of large cash deposits. Detective controls hinge on examination of transactions for violation of business rules, such as failures to disclose large cash transactions. Law enforcement and interbank cooperation results from “if, then” business rules that require notification and collaboration if certain conditions—such as a person making numerous foreign cash transfers—are met. Business rules are the connection between antilaundering controls and information systems. Business rules manifest as application logic that precludes unauthorized access to systems and flags suspicious transactions, and so on. As we move forward and learn about the role and potential of IT and EDA in anti–money laundering, we will be dealing almost continually with the design, application, enforcement, and audit of business rules.
Though many of the approaches to fighting money laundering are not reliant on technology—such as observing a nervous glance from a customer at the teller window or noticing that a tough-guy biker type seems to own a nail salon with an inordinately high cash flow—almost every serious and effective practice for catching money launderers involves checking for violations of business rules on banking systems or investigating patterns of transactions that are suspicious. Anti–money laundering is deeply rooted in IT, including many situations where IT supports a human practice or business rule.
Today, most banks employ a hybrid of IT, human, and organizational practices and processes to enforce business rules and investigate patterns of transactions that might indicate that money laundering is taking place. These practices range from systemically embedded rules, such as programming logic that precludes settling a large cash deposit without disclosure of the depositor, to sophisticated data analytics that can ferret out money laundering from millions of seemingly unrelated transactions. And, almost every antilaundering effort involves auditing, both continuous and periodic.
To see how IT and EDA fit in to the antilaundering process, we should clarify the difference between periodic and continuous audit. Most auditing done today is periodic, meaning that auditors look back over transaction records for a previous period of time and try to find evidence of money laundering. Experienced fraud examiners have established practices that can find criminal activity in the subtlest of clues. Figure 8.1 shows the systemic aspects of this kind of audit. In this example, the auditor examines data outputs from the mainframe-based bank transaction database and the distributed systems that log disclosures of large cash depositors. The auditor looks for exceptions to the business rule that mandates that large cash depositors fill out the disclosure form. An exception is an indicator that money laundering might be going on. The depositor who failed to fill out the disclosure will be investigated in greater depth.
Figure 8.1 Periodic auditing to catch money launderers involves the auditor examining data from different systems and looking for exceptions to business rules. In this case, the auditor looks for records of large cash deposits where the depositor has not filled out the government-required disclosure form.
A continuous audit, in contrast, works with relatively live data, perhaps even real-time transactions. As depicted in Figure 8.2, continuous auditing typically involves integration of the involved systems using an enterprise application integration (EAI) solution, and also the deployment of an exception monitoring solution. With this setup in place, the exception monitoring solution can check transactions for their compliance with business rules in real, or near real time. The exception monitoring solution can alert auditors or other responsible staff for suspicious rules exceptions as they occur, or in timely reports. Most credit card fraud detection systems work in this way, as another example. This process is sometimes referred to as continuous monitoring.
Figure 8.2 Continuous auditing against money laundering invariably requires some type of application integration (EAI) solution to be deployed to tie together the functioning of the systems that support the transactions under scrutiny. An automated exception monitoring solution checks for violations of business rules that might indicate money laundering.
There are pros and cons to both approaches to auditing, though we will see as we move forward that an SOA-based EDA has the potential to help both overall. A periodic audit is inexpensive from an IT perspective. The auditor can work from data exports from transaction systems or even paper printouts. And, periodic auditing is flexible from an IT perspective. The auditor can pick and choose what data sets he or she wants to audit and work with system output that does not require sophisticated integration. For example, the auditor could request a record of all cash deposits over $10,000 for a set period of time, and compare that record with the deposit disclosure records. Any deposits that lacked a disclosure would be good candidates for further investigation. The advantage of this situation from an IT, and cost perspective, is that it is a lot less expensive to generate reports that an auditor can examine than to conduct application integration that matches up such rule exceptions as they occur. This latter setup could enable continuous auditing. If you factor in the idea that the auditor can change the parameters of data output that he or she wants to see at any given time, the cost differential between simple periodic auditing and continuous monitoring become even more significant.
Continuous auditing has several major advantages over periodic auditing, though the approach comes with its own drawbacks. For one thing, in contrast to a periodic audit, a continuous audit can flag crime as it is occurring, not after. From a law enforcement perspective, this is a big plus. Being able to say crooks ran a billion dollars through our bank last quarter is not as good as catching them red-handed.
However, setting up continuous auditing is generally a lot more expensive than conducting periodic audits. The typical approach to continuous monitoring relies on proprietary application integration, and this pattern rapidly becomes unwieldy as it scales. Figure 8.3 expands our simplified example and shows the dependencies involved in implementing exception monitoring across multiple systems. Because money laundering can occur through a range of transaction types—such as loan repayments, offshore transfers, and so forth—multiple business rule sets must be checked for exceptions to catch suspicious behavior. At one bank, it starts to look like Figure 8.3. Imagine, then, what this approach to continuous auditing would require, in systemic terms, for achieving awareness of transactions at multiple banks in multiple countries. It quickly becomes impossible to manage, or at least pay for.
The costs of fighting money laundering are rising rapidly, and their increase is largely attributable to IT expense. As the Wall Street Journal article states, the cost of anti–money laundering has risen 60% from 2006-2007. Though part of the cost is training of employees to recognize patterns of crime, the article goes on to say, “Another cost is the computer systems that monitor transactions. The [KMPG] study found that a big challenge for banks is monitoring an individual’s transactions and accounts across multiple countries. ‘A significant proportion of banks could not carry out this type of monitoring,’ KPMG said, noting that less than a quarter of those surveyed with an international presence are capable of monitoring individual customer money flows.”5
In addition to pushing up costs of compliance and detection, adding the integration layers required for continuous auditing, at least under a conventional EAI model, also results in a lack of agility for banks. The banking industry is dynamic, with many mergers and acquisitions and strategy shifts. Indeed, as the KPMG report says, “Adding to the challenges is the increase in cross border banking mergers. They can introduce the headaches linking existing computer systems and meeting new standards and laws where the combined bank operates.”6 Ripped from the headlines, as we say! The IT costs of global multithreaded compliance are a huge “headache...” Banks are continually buying each other and expanding into new territories and lines of business. Each merger increases the risk of money laundering and also makes it harder and more costly to combat using an integration-centric continuous monitoring approach. For example, if a bank expands into investment services, it increases its risk of money laundering through the purchase of investment instruments. Mitigating this risk involves the implementation of additional layers of business rules and exception monitoring. Ultimately, the anti–money laundering efforts can impede business strategy, or they get relegated to subordinate priority in favor of the business needs, and the exposure to money laundering increases. What can be done about this? And, does EDA have a role to play in easing this seemingly impossible situation? The answer is yes. Let’s move forward and see how.
If banks had some way of being aware of all of the financial transactions that make up most money-laundering schemes, they would be more effective at fighting it. Now, of course, banks have a high level of awareness of the transactions that take place within their enterprises. And, groups of banks and interbank networks, such as wire transfer facilitators, have a record of the funds they move about. The real problem in combating money laundering is a lack of understanding about the associations between transactions. It is the connection between two seemingly unrelated transactions that could indicate an occurrence of money laundering. For this reason, EDA has great potential to help detect and prevent this crime.
Money laundering is a crime that occurs through a series of transactions, or a pattern of financial activity that creates a set of events. If software connected to an EDA can detect these suspicious transactions or patterns, the banks can have an easier time figuring out what is going on. At a high level, the ideal vision of an antilaundering EDA might look something like Figure 8.4. Figure 8.4 depicts an EDA for a single bank. Any system that could generate an event relevant to detecting or preventing money laundering—that is, one that is part of a detective or preventive control—publishes event information to the message backbone(s), which we call the event cloud. The rules engine(s) examines multiple event streams and historical event patterns to detect money laundering that is about to occur, or has just occurred. What we’re calling rules engines for the purpose of this discussion use event producers to send notifications to any necessary party, such as antifraud personnel, auditors, law enforcement, and so on.
Figure 8.4 The high-level vision for an EDA-based anti–money laundering solution has all of a bank’s systems publishing event data—transactions, account creation, debt repayment, and so on—into an “event cloud,” to which a set of rules engines subscribes. The rules engine, which functions in this case as an event listener and event processor, feeds suspicious transaction data to a set of reacting systems, including a continuous audit program, an automated account flagging application, and whatever automated notifications are required, such as for law enforcement.
Putting this high-level EDA vision into the context of an actual money laundering pattern, let’s imagine that we work at a bank that wants to monitor suspicious debt repayments. Rapid repayments of loans are a sign of possible money laundering. As shown in Figure 8.4, which adds some specific event data to our idealized model, a series of events hints at money laundering if they can be correlated and examined in near real time. In the example, a person named John Doe takes out a car loan in the name of a business he owns, and then pays off the loan three days later. Could he be laundering money? For the purpose of our example, he is—so let’s see how our EDA could be used to detect or prevent this kind of activity.
In the normal course of events, at a bank where application integration and audit are limited, the bank might not notice a few suspicious things about Mr. John Doe and his car loan. A casual observer might think that he just refinanced, or asked his mother to pay off the note... so the trick is recognizing that this particular payoff is suspicious. If we were able to use our EDA to listen to events related to customers, we would recognize that this transaction is suspicious. So, the trigger event might be when John Doe pays off his loan three days after it was established. The small business systems generate an event that indicates that John Doe owns four businesses, each in a different Standard Industrial Classification. (Code mismatching between business types, account holders, and transaction types is a classic sign of fraud.) The loan processing system generates an event confirming that John Doe has paid off the car in three days. The checking account system publishes an event indicating that John Doe has written 50 checks to “cash” this year. The branch systems generate an event indicating that he paid off the car loan in cash. The loan origination system generates an event indicating that he has bought eight cars recently for his four businesses. And, the loan securitization system publishes an event indicating that each car was pledged as collateral for each car loan and has been released as collateral upon repayment.
These and other events trigger publication to the bus. Some information is always reviewed, whereas others might be dynamically selected (either at random or due to some initial pattern match), and an anti–money laundering listener decides which ones to look at. After being picked up, the system might publish events back to the bus looking for specific data, then correlate this information and make some kind of a decision as to which events get published back to the bus. Multiple listeners could pick this event up—some, for example, might flag accounts to be monitored more closely, others might automatically block wire transfers, and so on.
As the EDA publishes event data to the subscribing event processors—in this case, the rules engines—these processors can then, in turn, publish their own event data that flags suspicious transactions connected to John Doe. Figure 8.5 illustrates this flow. The takeaway here is to see how the EDA can be dynamically extended to different tasks by different stakeholders. These stakeholders don’t have to be associated with each other to perform these functions. In this case, for example, the person who runs the rules engine application can configure it to publish suspicious loan repayment transactions. This person does not have to know, or even care, what will be done with the output of the rules engine once the subscribers access it. That is the beauty of EDA. The reality is that money-laundering detection and prevention changes constantly, especially in the context of a large bank. In a large bank, a debt refinancing marketing program could spark a large number of suspicious loan repayments, which all turn out to be totally legitimate. How many “0% credit card payoff” solicitations do you get in the mail every week? Initiatives like this could easily create many false positives from a detection perspective. The rules engine that flags suspicious repayments can work without preconception of these programs and publish suspicious transaction data to the enterprise service bus (ESB). Another rules engine can subscribe to these events and weed out the repayments that are caused by a debt refinancing promotion.
Figure 8.6 shows a simplified version of a global EDA approach to anti–money laundering. Multiplying our single bank, with its event cloud, worldwide, you could use an EDA approach to create regional event clouds—ESB clusters, in reality—to aggregate event data from across multiple banks. Antifraud systems and rules engines could parse event data and discover potentially suspicious transactions. In the end, you have a set of event clouds that connect with one another using the Web services standards. The net result would be a way to handle global multithreaded compliance.
Figure 8.6 Global anti–money laundering using EDA involves connecting multiple event clouds, or ESB clusters. Though the standards can facilitate this, the practicalities of getting such a complex structure off the ground are quite daunting. However, even with a partial solution, the banking system might have an improved method of reporting on global compliance.
Before we celebrate our solution, we need to go up a few more levels and see how challenging the EDA approach to fighting money laundering can be from a global perspective—not to mention the other regulatory issues to be addressed in such an approach. Even in this stripped-down version, you should be able to see how complicated and costly such a solution could be. Nevertheless, this approach is an interesting case in which to discuss AML handling across multiple banks in a standard, reliable way.
The good news about EDA as an anti–money laundering solution is that it can be deployed gradually and have a measured impact as it grows. In contrast to the FEDA system for the airlines, which needed to deploy pretty much in a fully grown state, a bank’s anti–money laundering EDA can be developed to tackle one set of money laundering at a time. For our descriptive purposes here, the incremental approach fits well. We take a deeper dive into the loan repayment pattern of money laundering that we have begun to explain in the John Doe case and show how an EDA can be built to solve this particular type of fraud. As we go through it, though, we also highlight ways that the EDA can be extended subsequently to combat a broader array of frauds.
Figure 8.7 shows an architectural view of the event producers in the antilaundering EDA. In this case, where the bank is trying to detect suspicious rapid loan repayments, it uses common (perhaps existing) Web services to function as event producers that publish event data about loan repayments and related transactions to the ESB. As the figure shows, the event Web services are not specifically designed to be part of the EDA. Rather, in keeping with the architectural principle of minimizing preconception among EDA components and reducing central controllers, this EDA relies on event data produced from workday activities that already occur in the relevant systems. In the example, the loan processing systems generate event data about loan payments through a Web service called PostPayment. The checking account system produces event data through a Web service called DebitAccount, and so on.
As these systems process their workloads, the Web services send messages containing state information, published as event data, in SOAP XML. Thus, if John Doe pays off a car loan with cash at a branch teller window, the teller processes the receipt of the payment through a loan payment processing application that was developed using Web services, a business process modeling (BPM) tool, and an ESB. In the service-oriented architecture (SOA) world, this would be called a SOBA, or service-oriented business application. (See Table 8.1 for a breakdown of event Web services that are part of the loan payment SOBA.) The Web services used by the SOBA generate the state change information that the antilaundering EDA can consume and process. As you can see, the Web services used in the loan payment processing SOBA are the very same ones we call event Web services in Figure 8.7. As with so many EDAs, the regular workday Web services used for business processes do double duty as event services.
Figure 8.8 shows the business process model (BPM) view of such a loan payment processing SOBA, and the Web services that it invokes. The teller receives the cash payment, inputs the payment details into the loan processing application, posts the payment, and issues a confirmation to John Doe that his loan has been paid off. The remainder of the business process model requires that the loan processing application close the loan account and release the collateral from the loan. If the bank is using a suitable SOA platform to develop this SOBA, they might be able to generate a Business Process Execution Language (BPEL) document that orchestrates the Web services into the business process model.
As each Web service in this loan payment processing SOBA is invoked, it sends a Simple Object Access Protocol (SOAP) message to the consumer using the ESB as its messaging backbone. From an EDA perspective, these SOAP responses are notifications of state change emanating from an event Web service. To reiterate, there are no specific event Web services in this case. However, the EDA uses the SOAP messages of the day-to-day SOBA to discover the state changes it needs to produce event data and generate an event stream.
However, and this is a very important idea to grasp, the Extensible Markup Language (XML) schema of each Web service in the SOBA needs, to some great extent, to conform to the event data needs of the EDA, or the EDA won’t work. For the best of reasons, many messages used in application integration are extremely succinct. For example, if the SOBA developers are working off their standard EAI playbook, they might design a SOAP request for CashLoanPayment that says, in effect, “for this account number, yes, we have a cash payment.” The application that is exposing the CashLoanPayment Web service (the loan processing system) understands what this means and handles the message accordingly. There’s nothing implicitly wrong with this. But as we have discussed, this type of abbreviated XML schema creates a high level of preconception and dependency between the Web service and its consumer. The consumer and Web service need to know a lot about each other to work together, which tightens the coupling between the two. This is antithetical to good EDA design, partly because EDAs revolve around loose coupling, but also because there is no description of state change contained in the message. An event listener would have to be very dependent on specific application integration patterns to discern the state change occurring here. In contrast, if the event listener can parse the SOAP message, it will have a much easier time understanding exactly what change in state is occurring, and be able to flow this event data into the event processor with less dependency on the EAI patterns. The event processor can look at the XML and understand that a given loan was paid off in cash on a certain date without having to know very much at all about the EAI patterns involved. Of course, there is some degree of dependency. The event processor needs to know the XML schema, and it needs to know the syntax of the SOAP message and what an element like PayoffYN (for example) means. There needs to be a data dictionary and XML schema sharing. However, the richer the state change data flowing in the SOAP messages, the simpler it will be to develop a dynamic, efficient EDA.
To help make the EDA development work better, the respective EDA and SOA teams can take advantage of the BPM and BPEL platform tools. Though not essential, these capabilities can smooth the way toward getting an EDA off the ground leveraging an existing SOA or SOBA. The BPM approach is helpful because it allows those responsible for the EDA and the SOA to collaborate and gain understanding of the others’ designs, needs, and outputs.
On their own, the data contained in these SOAP messages does not tell antifraud staff or rules engines much about possible money laundering. Taken together, though, they can present patterns that can be identified as suspicious. The event processors, which might be rules engines, look at sets of messages that they flag based on their anti–money laundering criteria.
As the event listeners and event processors detect suspicious activity, they set off a cascade of secondary event processors and event listeners. For example, when the event processors flag John Doe’s loan repayment as suspicious on the grounds that it was (a) a cash payment and (b) paid off within a short period of time, the event processors should then run a query to see whether several additional suspicious aspects of money laundering are also present. It should query event listeners on the ESB to find out if there was collateral for the loan, and whether it was released, and also query to see if John Doe has paid off a loan for cash in the past. If these two queries return positive results, John Doe should be flagged and brought to the attention of antifraud staff. This flow of flagging and query is shown in Figure 8.9.
Figure 8.9 This expands Figure 8.8 to show the event listeners and event processors that flag suspicious loan repayment transactions and pass them along for further queries and possible alerting of antifraud staff and audit.
There could be a good reason for John Doe to be paying off loans in cash. He might be in a cash business, for example, or he might just be someone who likes dealing with cash and recently took advantage of a home refinancing program. At some stage, a person must get involved to sort out what is going on. The point at which a person needs to get involved is a measure of how efficient the EDA is. People tend to be expensive, in terms of their time and availability. Ideally, the EDA will be good at flagging real money launderers, and skip false positives. False positives are costly because they consume antifraud resources. In fact, the false positive (and perhaps false negative) rate is a good metric to include as you evaluate the success of an anti–money laundering EDA.
Again, though, the takeaway for this is the activities of the antilaundering EDA are independent and loosely coupled with the functioning of the bank’s operational systems that feed the event data into the ESB. The antilaundering EDA needs to be dynamic and flexible, able to pivot rapidly to investigate ever-changing business rules and patterns of detection. It needs to be adaptable to changes in internal controls. If the EDA can only adapt to internal controls by requiring significant changes in underlying systems and their points of integration, the EDA will be very inefficient and probably not work well at all. Let’s keep this concern in mind as we look at the specific challenges of getting an antilaundering EDA up and running in real life.
Now that we have had a look at how an antilaundering EDA might work, we can think about what would be involved in creating a working, effective EDA that would help fight against money laundering throughout a bank and all its operations and among other banks. Are you ready for another code name? Imagine that we all work for a bank that wants to use EDA to help in its fight against money laundering. Our project will be known as the Event-Driven Internal Controls Tracking System or EDICTS.
The goal of this section is not to repeat the basic EDA precepts we have elaborated on before. It is a given that EDICTS will consist of loosely coupled Web services, lack of a central controller, and so forth. Our goal in this section, rather, is to highlight certain essential requirements that would make EDICTS a worthwhile use of time and resources. In particular, we look at ways of solving the challenges of adaptability, relevance, and continuing success of the endeavor. One risk faced by new technologies is a long-term failure if a paradigm is not adopted with a long-term view. Many great ideas flourish at launch but then languish as IT and line-of-business managers return to activities that they perceive to be of higher priority and neglect the benefits of the new approach. The result of this cycle can be a relapse to firefighting mode and bandied solutions to chronic problems. We don’t want this to happen to EDICTS!
As a change of pace, we describe the organizational and business issues at the same time as we develop the technological plan for EDICTS. Rather than breaking them out separately, as we did in the previous chapter, in this case we want to illustrate how these factors are interdependent. As we have often learned the hard way, there is really no difference between business needs and IT needs, no separation between politics and technological solutions. The greatest project in the world will either fail or evade funding if it doesn’t satisfy the thorny and overlapping requirements and agendas of all stakeholders. And, as we hope to point out in this story, even stakeholders who lack direct power in the organization can be quite influential when it comes to validating the idea and delivery of an innovative technological solution.
Let’s face the reality that we are already far out on a limb if we are designing a system, and hitting up execs for budget, that falls into the compliance and security category. Despite the clear risks associated with money laundering, it is not always clear which stakeholder holding the purse strings at a bank is responsible for risk-related expenditures, particularly when they cross product and channel lines as this one does. The struggle for funding and endorsement can be even more difficult if the solution involves a new technology approach such as EDA. One of the biggest challenges, then, is to be relevant to stakeholders from the outset, in terms of functionality, nomenclature, and outputs. EDICTS will fail if it is not relevant to all its major stakeholders. Relevancy must be designed in from the very beginning.
With relevancy in mind, let’s make an assumption. If EDICTS is intended to help auditors and antifraud staff do their jobs, but it is established as a wholly separate system that these people will have to master, it will be severely challenged. Instead, we think the best practice for this type of solution is to assume that it should be embedded into the existing workflows and practices of its key stakeholders. For this reason, we came up with the EDICTS name. The idea of controls is built into the solution’s identity. The requirements, features, and functionality of EDICTS should relate to established antifraud and antilaundering internal controls practices. In addition, the descriptions of EDICTS, its proposals, requirements, and documentation should reflect the language and mind-set of information security professionals, auditors, and antifraud specialists. As a first step, let’s list the stakeholders and understand their needs for EDICTS, as shown in Table 8.2.
Table 8.2 breaks out EDICTS’ stakeholders and describes their regular business roles and expectations and requirements for EDICTS. What you should be able to see in this table are forces of simultaneous alignment and tension between the vision of EDICTS and the working responsibilities of the stakeholders. Yes, of course, everyone has an interest in, and incentives for, reducing money laundering. Yet each stakeholder has existing job functions and incentives that are in conflict with EDICTS. For example, while the branch banking staff might find EDICTS to be helpful in flagging suspicious accounts and customers earlier in the money-laundering cycle than existing controls can ensure, these same staffers might rebel if EDICTS slows down their system performance to the point where customers are dissatisfied with their level of service.
In a similar vein, the information security and corporate security groups have a strong interest in curbing money laundering. However, like any other business unit, they are limited in terms of headcount and resources. If EDICTS is designed in a way where it requires additional personnel, that could cause a conflict. Even if funds are made available for hiring, there could still be trouble with EDICTS. For instance, there is often a disruptive lag time between the identification of an open position and the hiring of a suitable person. In the case of an EDA, hiring the right professional might be quite challenging. If EDICTS generates “empty seats” that must be filled, and those seats cannot be filled in an adequate time frame, the whole launch and operation of EDICTS could suffer, possibly even detracting from other antifraud efforts. At the design stage, EDICTS program managers should be aware of this potential execution risk and try to plan ahead for its solution.
Identifying the best owner for the overall EDICTS program is ultimately one of the key ways to solve the tensions between stakeholder needs and EDICTS requirements. If EDICTS is hatched as a pet project of the chief architect and managed by the IT Department, it might fail to launch properly. The group that owns EDICTS must be vested with an incentive for its success from a business perspective. This idea is not unique to EDICTS, and can be transposed to other situations in corporate life where an EDA adds needed but not absolutely essential functionality to a business operation. The truth is the bank could survive without EDICTS, even if the program will make everyone’s life easier. Determining who should own EDICTS, and where the program should “live” after its launch, is of great importance for its long-term success.
It’s not obvious who should own EDICTS. The CISO might be a good choice, but CISOs typically don’t manage systems for the long haul. Rather, they usually advise IT and business management on security policy. The best place for EDICTS is probably the antifraud business unit. They are the people who are most responsible for fighting laundering, even if the obligation filters out to many other groups and people. That being said, a number of other groups still need to take significant responsibility for the success of EDICTS from a technological, financial, and management perspective. Table 8.3 breaks out the roles and responsibilities of key stakeholders for the ownership and control of EDICTS.
The trick to getting EDICTS off the ground and running is aligning each stakeholder with the success of the program. This is far from simple, but it can be done. The antifraud unit will own EDICTS, but the program needs active buy-in at every level. EDICTS needs top-level executive sponsorship, which means, to a great extent, a long-term commitment to funding as well as resolution of agendas. The architecture and IT groups need to be given a clear mandate to execute EDICTS as well as the opportunity to have input on its requirements and technological implementation plan. This might mean that EDICTS is folded into a larger SOA corporate standard and project set. The information security and audit groups need to be on board with EDICTS and given the opportunity to have input on its nature. The extended business units need to participate in the launch and continued operation of EDICTS, so it would make sense to have EDICTS adoption built into the management plans and incentives of those units.
Another possible enabling factor for the launch of EDICTS could be the use of banking industry groups and standards bodies, as well as existing IT industry standards bodies. Though it is early in the technological life cycle of EDA, there are many industry organizations that set data compatibility standards for banks on a national and global basis. These groups, such as the European Committee for Banking Standards or OASIS, have already laid the groundwork for a program like EDICTS. For example, the emerging standards of SCA (Service Component Architecture) and SDO (Service Data Objects) are gaining attention from banks because of their ability to drive rapid adoption of service orientation.7
The thing to remember in this assignment of roles and responsibilities is that you are not dealing with a benign phenomenon. Money laundering is a serious crime and the failure to detect it could lead to major repercussions for the bank. As a result, careers could be at stake. If you were in charge of planning for the development of EDICTS, you would likely face more intense political wrangling than you would in a standard IT project scenario.
EDICTS will have an ever-changing requirements set because combating money laundering is a constantly shifting process, and one that touches many different areas of a bank’s operations and network of partners. In actuality, the EDICTS requirements set needs to pivot in two directions. In one direction, EDICTS needs to be capable of nearly endless updating in its extant functions. The specific way that a fully realized functional requirement works against money laundering will shift over time, so there needs to be a way to conduct subtle changes in the system with minimal cost and downtime. The second pivot involves extensibility. EDICTS needs to expand its scope of antilaundering. EDICTS needs to be able to add new antilaundering functions that involve previously untouched systems, in a cost-effective manner.
At a high level, with these two requirements pivots in mind, we can formulate a basic definition of EDICTS as the following: EDICTS should be a solution that contains both hot swappable rules processing components and a built-in platform for low-cost extensibility. EDICTS needs to be capable of centralizing business rules processing functionality in such a way that rules can be updated without undue stress or modification of dependent system parts. It should also have, built in, an interface or platform for continued extension that can be performed without undue disruption to the working parts of the system.
Given these two core assumptions—of updatability and extensibility—the way the requirements are implemented might still vary depending on the optimal setup within the bank. For instance, it might make sense to create a complete and isolated development and test environment for EDICTS, a dedicated hardware and network operation, and a dedicated software infrastructure such as ESB. Alternatively, EDICTS could be integrated into an extant, broader-based software development team and its Integrated Development Environment (IDE). Of course, this chapter is intended to provide a guide to thinking about developing an EDA, and individual results might vary. Indeed, your bank might have different needs, or you might have nothing to do with the banking industry at all.
Whatever the specific implementation looks like, though, EDICTS needs to have an architecture that contains the following components:
A modeling interface—EDICTS’ business owners, the architects, and the developers must all be able to collaborate in the modeling of the antilaundering logical flow in the form of a business process model.
A mapping of requirements to internal controls—For the sake of relevance, and avoiding the creation of a duplicative workload, EDICTS’ requirements should be rooted in the existing internal controls framework of the bank. EDICTS is a mechanism for implementing detective and preventive controls, so it makes sense to build its requirements gathering and implementation into the internal controls work stream.
A development interface—The business process model should translate to the development of a software application that orchestrates the event listeners, producers, and processors, though without necessarily implementing central control of those elements.
A flexible rules engine—Ideally, the business rules segments of the event processors should be independent from the rest of EDICTS in terms of hard-coding. The rules themselves, as well as the inner quantitative nature of the rules, will change constantly. To be dynamic, EDICTS should have rules components that can be plugged in, or unplugged, with relative ease. This might mean the use of rules Web services that can be deployed with few, or no, tightly coupled dependencies on the rest of EDICTS.
A planning and collaboration solution—With its numerous and varied stakeholders, EDICTS needs to include some kind of collaboration tool. Whether this would be a stand-alone portal or application like Microsoft Groove, or a part of an existing collaboration workspace, would depend on the details on the ground at the particular bank. However, the requirement is still strong. EDICTS stakeholders need a place, ideally a virtual one, where they can share their workload, assign tasks, set schedules, engage in feedback sessions, and so forth, to drive the program forward on an ongoing basis.
Figure 8.10 lays out the reference architecture for EDICTS’ development, test, and production environments and shows the connections to the stakeholder groups. Each stakeholder can monitor the progress of EDICTS at the development and test stage, an activity that essentially never ends given the perpetual upgrade mode of EDICTS. The SOA governance loop is a key concept to grasp in this architecture. Web services and their consumers need to be developed and tested with governance policy applied. Then, when they are deployed into production and set up on the ESB (or equivalent), those same governance policies need to follow them in an auditable fashion. In organizational and procedural terms, the EDICTS IT team and whatever group in IT that manages the SOA must be in tight synchronization. For practical purposes, as well as for the sake of project viability, they might even be the same people.
Figure 8.10 A basic reference architecture that shows how the planning, development, and production segments of EDICTS can work together. Before specific requirements are set, the stakeholders will need to agree on this architecture, which includes interfaces for collaboration between stakeholders as well as governance and deployment factors.
Now that we have a workable reference architecture for EDICTS that maps to stakeholders, we can start defining actual requirements of EDICTS itself. Though it might have seemed counterintuitive, we needed to go through the elaborate stakeholder analysis, program ownership process, and reference architecture for development, test, and deployment before we can really look at requirements. Although in many standard system development situations, the evaluation of stakeholders can be conducted iteratively during requirements gathering, in the case of a complex, sensitive, and interdependent program like EDICTS, survival might depend on nailing the ownership and stakeholder mix just right at the outset. Also, in contrast to most system development efforts, where the owner is known at the start, EDICTS is so potentially broad that it’s ownerless before it begins.
Continuing on our quest for long-term relevance, which translates into program survival, we suggest that the specific requirements of EDICTS map closely to the bank’s existing internal controls over its financial operations. There are several reasons for this. For one thing, in keeping with our stakeholder alignment and interest in efficiency, we do not think it would be wise to create a wholly separate work stream and set of functions for the antifraud staff to master as they combat money laundering. The antifraud staff, and its corollaries in accounting, operations, and audit, also work from the same internal controls set. Plugging EDICTS into those controls gives EDICTS a seamless and practical connection to an existing and well-understood work stream.
To define requirements, therefore, we need to first understand the internal controls that mitigate the risk of money laundering. Most internal controls are based on a framework known as COSO,8 which involves matching risks with control objectives and control procedures. (COSO is an acronym for Committee of Sponsoring Organizations of the Treadway Commission, a widely adopted internal controls framework for financial reporting.) For example, the COSO approach to the loan repayment money laundering trick for car loans might look like what is shown in Table 8.4.
Looking at this control setup, it might seem quite obvious to you or me that the bank needs to have procedures such as these in place to detect and prevent money laundering. However, what you need to understand is that the process described in the table, which in real life would include dozens or even hundreds of such control pairings, is designed to mitigate the risk of fraud systematically. Antifraud staff, working with auditors, first determine their control objectives. Then, they work through the risks to the attainment of those objectives, and finally, develop control procedures to mitigate the risks. If we are tasked with developing requirements for EDICTS, then we can take some comfort in understanding that a lot of the heavy lifting around EDICTS’ antilaundering objectives and procedures for realization of those objectives has already been done for us. Our job, as definers of EDICTS requirements, involves figuring out the optimal way for an EDA to implement the control procedures already agreed upon by the antifraud staff, the line-of-business owners, and the auditors. Looking at it from another perspective, our work on EDICTS is a supplement to the existing work programs undertaken by these business groups. EDICTS can help them in their antifraud efforts without bogging them down in new, extraneous mastering of tasks and processes.
One final note on the importance of matching EDICTS requirements to internal controls: When the auditors (internal as well as external) conduct their audit of internal controls, they will be looking for evidence that the control objectives have been met through the control procedures. Once again, by matching EDICTS requirements to the existing internal controls, it is possible to add a high level of auditability right into the solution. It would be counterproductive, or even destructive, to the interest of EDICTS to require a new audit workload.
Figure 8.11 takes the EDICTS production system from Figure 8.10 and expands it into a basic reference architecture to show the major components needed to make EDICTS function in alignment with its internal controls mandate. At the core, we have the EDICTS management console. Like any enterprise application, EDICTS needs a control interface. This management console would contain both regular user and administrative functions. Regular users of the system, such as the antifraud staff, would use the management console to generate outputs necessary for checking the activities of detective controls. They would also use the management console to configure the pluggable business rules to match internal controls.
Administrators would use the management console to set up EDICTS and maintain it as a system on an ongoing basis. The administrative features would include capabilities for plugging and unplugging business rules, connecting event listeners with event producers, and interfacing with the SOA governance solution and SOA governance loop. Table 8.5 shows an approximation of the administrative interface of EDICTS. The table extends the COSO internal controls pairings shown in Table 8.4 and matches each control procedure with a set of event Web services and business rules.
Table 8.5 is also a representation of the way that functional requirements for EDICTS could be documented. As we have discussed, the requirements for EDICTS will match internal controls. To make this happen, each COSO control objective, risk, and control procedure needs to be paired with functional requirements that spell out the specific Web services and business rules that will be used in enacting the control procedure. As EDICTS grows in functional scope, its requirements can be fitted to an expanding set of internal controls.
The Alerting/Reporting Module has two separate but related functions. It is able to send real-time alerts about suspicious transactions to antifraud systems. In addition, it can generate reports of EDICTS system activity, including logs of transactions and analysis of transaction flows with money-laundering patterns applied. In the first case, which is a real-time, or near-real-time process, EDICTS helps enforce preventive internal controls. By alerting antifraud staff, and systems, of possible improper activities, EDICT can prevent money laundering.
In the second case, where EDICTS is providing information about transactions occurring in a prior period, the system is supporting detective internal controls. Auditors can review the reports and analyze them for patterns of money laundering or transactions that might indicate money laundering occurring in another branch of the bank.
Though the reporting function can be run as a stand-alone application, we suggest that the alerting and real-time reporting capabilities of the module be designed as EDA components themselves. The alerts, which are an output of EDICTS, are generated by event producers and published at the ESB level. Any system that needs to receive those alerts, such as the antifraud systems, can subscribe through event listeners. Extensibility and flexibility are two advantages of this approach. As EDICTS grows, it might be desirable to connect real-time alerts to a whole range of systems, such as ATMs or loan processing systems, that might not even exist yet! The EDA approach gives EDICTS a lot of adaptability into the future.
In Figure 8.11, we depicted the banking systems feeding event data into EDICTS as service-oriented business applications (SOBAs). This might be somewhat optimistic, as in reality most of the bank systems will not be SOBAs, at least in the near future. However, we chose to represent them as SOBAs to emphasize the optimal nature of exposing event sources as Web services and to emphasize the importance of aligning the EDA development efforts with whatever SOA program is unfolding at the bank.
For optimal economy and reduction in incompatible architectures, EDICTS should be built in tandem with the bank’s SOA. Though we have discussed the EDA/SOA connection through the book, in this chapter, we want to focus on several selected areas of relevance. In particular, we look at the value of joint planning by the SOA and EDICTS teams, compatibility of development environments and practices, and alignment of SOA and EDA governance.
As many of us learned the hard way, what appears to be a technology problem is actually a human or organizational matter. To make EDICTS a success, it must be designed in keeping with the SOA standards that are defined for the bank globally. We are assuming, of course, that there is an SOA at the bank, and that the bank has formed committees to define their particular SOA standards. In our view, this is a good assumption for any well-run financial institution.
The people who are building EDICTS need to be invited to participate in the SOA planning and management process. EDICTS needs a seat at the table, or at the very least, access to the bank’s SOA standards. At the same time, the EDICTS team needs to know that they are expected to follow the bank’s SOA standards.
For example, SOAP schema coordination is an area where joint planning between SOA and EDA teams can benefit both EDICTS and the bank’s overall enterprise architecture. As an EDA, EDICTS relies on having Web services that carry event state within their SOAP messages. The SOAP schema that carries state might not automatically be the type specified or preferred by the SOA teams. In fact, they might have good reasons for not wanting such a schema. This is a matter to be resolved.
It might seem obvious that it pays to set up the SOBA with Web services that carry state in their SOAP messages. However, in reality, there are a number of barriers to achieving this objective, some of which are rooted in well-established principles of system design. For one thing, security standards might require that messages not contain excessive amounts of private customer data. It is more secure to send an abbreviated message, for instance one that contains only a portion of an account number, than a message that contains the account holder’s name and account number. The exposure to the threat of message interception can be offset by the countermeasure abbreviated message syntax. The problem, of course, from an EDA perspective, is that you lose your state carriage in the message. At the level of infrastructure performance, the larger messages required to carry state can slow down the network traffic. Then, there is the simple issue of awareness. It is easily possible for developers to go about their work on the SOBA without realizing that they were supposed to create XML schemas that carried state in the SOAP messages. Once their SOBA is finished, tested, and deployed, it will be too late to go back and retrofit the SOBA’s Web services to EDA state carriage format without incurring additional expense, use of resources, and time.
There are solutions to both of these problems, but each solution requires forethought, especially in advance of the development of service-oriented applications. If messages, especially those traveling outside of corporate networks, are forbidden from containing a high level of account detail, they might need to be encrypted (if link-level encryption is used, there is a whole class of security issues that need to be solved, such as replay attack vulnerabilities, and so on—but they exceed the scope of this chapter). Network performance issues need to be addressed, and so on. However, budget and enthusiasm for the extra security elements and network capacity might be limited and it would be unwise to assume that the performance drag brought about by an EDA will automatically be resolved by the network operations folks at your organization. Preplanning and joint team coordination are essential to ensure success.
It might not be reasonable to expect the various SOA and EDICTS delivery groups to standardize on one type of development environment and server architecture. Sharing development practices can go a long way to ensure that the bank develops its SOA using any number of Web service IDEs and enterprise service buses, or equivalent server technologies, so we should assume that EDICTS will be assembled out of components from that SOA. As we know, SOA creates connectivity between heterogeneous systems. However, as we also know, in reality there can be subtle differences in standards and technology implementations among different vendors that can cause frustrating and sometimes costly delays and hassles. It’s good to be aware of issues related to IDE incompatibilities and adjust for anticipated issues in the shared development practices within your organization.
It’s important to have a consistent process and toolset for checking code in and out of development—this can help streamline the life cycle (SDLC) of EDICTS, as it will flow with that of the SOA. Ditto for testing procedures. Uniform testing and release, as well as patch management, will cut costs and confusion from EDICTS. From a high level, it would make sense for EDICTS to be seen by IT managers as simply another SOA-related development project, not a unique or high-maintenance endeavor requiring special resources.
Having a single set of development skills, as well as test and deployment processes, will simplify the training process for both SOA and EDICTS teams. Ideally, the bank should not have a group of developers who are well versed in EDA techniques and a separate group that is familiar with Web services and SOA but not with EDA. There should be one pool of IT talent to draw from, a state wherein the bank can have the greatest degree of flexibility to apply staff resources to projects. Also, if the goal is to establish EDA-friendly SOAP schemas and other best practices in the SOA that can enable extensible EDA projects, then joint training and cross-training are all the more compelling to consider.
Effective governance is crucial to ensuring that EDICTS can function properly and fulfill the challenge of being endlessly adaptable and dynamic. It is only with governance, which ensures that the system operates as intended, with secure and appropriate access to data, that EDICTS will have any integrity. However, the governance must also be flexible enough to adapt the many planned and unplanned future changes in EDICTS makeup.
It might seem counterintuitive to make governance the last item of a requirements discussion. In the SOA projects we have participated in, the discussion of governance comes, if not first, then right at the start of requirements setting. In the case of EDICTS, though, we felt it was necessary to establish all the stakeholder roles, reference architectures, and connections to internal controls before getting into the governance discussion. If we had not gone through these preliminaries first, the specifics of governance would lack relevance.
We should also assume that we are not going to develop a governance solution for EDICTS from scratch. That would be a huge waste of time and money, and probably wouldn’t work that well, either. Instead, EDICTS should be governed by the bank’s SOA governance solution, but with some adaptations.
Yes, SOA governance is SOA governance. But, with EDICTS, several factors need extra attention. For one thing, EDICTS is bound to connect to a great number of external users and systems. Whatever policy setting mechanisms are established for external access must be very thoroughly checked for secure provisioning of access privileges to EDICTS’ Web services. In addition, EDICTS is not the typical application running with its logic controlled centrally. The invocation of its Web services is likely to be a lot more unpredictable. The nature of EDICTS results in more passive consumption of Web services than a conventional SOA, where consumers and providers are matched closely for the purpose of defining governance policies.
On another level, the SOA governance for EDICTS should map to the bank’s internal controls. This is necessary for several reasons. It would be terrible if EDICTS accidentally exposed the bank to more security and control risk through deficient governance. And, the same internal controls that EDICTS is helping to enforce now include EDICTS by design. The owners of those internal controls need a way to validate that EDICTS is being well governed, and that its governance is in alignment with the control objectives and control practices. Further to this idea, EDICTS will probably be subject to different, likely stricter, audit requirements than other applications. The governance solution must be able to generate audit reports of system activity, as well as system findings and data, in a manner that satisfies the auditors.
Finally, the serious criminal nature of money laundering requires that EDICTS be secure from the inside out. As any experienced information security expert will tell you, internal threats, including personnel, can be the most difficult to mitigate. The EDICTS governance solution must have a layer of policy that enables extra security so that the watchers of the system can be watched themselves. Or, perhaps, the administrators who manage the EDICTS governance solution must be subject to strict segregation of duties. For example, there might need to be dual permissions required to provision access to the EDICTS governance solution. If that policy were not in force, an administrator could provision himself with access to the system and potentially modify it without being detected.
Though there are many equally valid approaches to governing an SOA and EDA, we will assume that the bank is using an SOA governance solution that utilizes a central policy store for policy definition and distributed agents for policy enforcement. With that in mind, but without going over every nook and cranny of Figure 8.12, let’s take a look at some of the highlights of SOA governance that are relevant for EDICTS:
Figure 8.12 This figure shows the relationship between a comprehensive SOA governance solution, including Registry and policy metadata repository, and the working parts of EDICTS. Web services intermediaries intercept SOAP messages traveling from consumer and provider through ESBs and enforce policy. Design-time and runtime governance are managed through a closed-loop approach that unifies policy definition and enforcement across EDICTS’ SDLC.
Registry/UDDI—One aspect of EDICTS as a production system that is so pervasive it is difficult to diagram is the UDDI registry at the heart of the bank’s SOA and EDICTS. As we have discussed earlier, every Web service in the bank, as well as those in certain partner organizations, needs to be listed in the registry for the SOA and EDA to function in a governable fashion. We are assuming, of course, that the UDDI registry connects with a set of SOA governance policies stored in a policy metadata repository. The UDDI surfaces through the management console so that administrators can connect EDICTS with necessary Web services, and also provision access to EDICTS’ own Web services, in a way that is consistent with the bank’s overall SOA governance approach.
Policy metadata repository—The policy metadata repository, which might be joined at the hip with the Registry in some vendor implementations, contains the governance policies that need to be enforced for each Web service in the bank, including those that connect to EDICTS. The policies contained in the repository govern such factors as access rights for Web services, including secondary and tertiary access rights that are passed along as tokens from human users, encryption, ESB federation and mediation, and provisioning of access to external users.
Intermediaries—SOAP intermediaries, both on the consumer and Web service side, are the policy enforcement points that assure system owners that the Web services are functioning as intended, in terms of security and reliability. There are several varieties of intermediaries available in the industry today, though most utilize a pipeline architecture that enables the administrator to switch policy enforcement on and off for both the outbound and inbound SOAP message flows. For example, in EDICTS, it might be necessary to encrypt a SOAP message that contains account holder information. The SOAP intermediary would cause the SOAP message to be encrypted and thus comply with the governance policy.
Performance monitoring—With a large number of potential Web services necessary to make EDICTS function, it is essential that its constituent Web services be reliable. System administrators need to know if a service is slow, or down. And, if a service goes down, it needs to failover to another instance of the service, or, at the very least, let someone know that it is down. Performance monitoring is another type of governance policy. The policy metadata repository should contain performance monitoring policies for EDICTS’ Web services. For example, EDICTS might require that bank Web services publish data every 60 seconds for the system to be up to date on the latest transaction flow. If a Web service is slow, or fails, the system administrator needs to know. This can take the form of an alerting process, such as Simple Network Management Protocol (SNMP) alerts to a system management console. Some SOA governance systems even have contract functions where Web service consumers and providers can come to an enforceable agreement regarding performance parameters. Beyond this, many SOA governance solutions offer the capability to map dependencies between linked chains of Web service consumers and providers. If these dependencies are not tracked properly when EDICTS is being developed, and especially as it is expanded, certain Web services could be subject to unsustainable load and break the system. In some cases, it might be possible, and desirable, to connect the SOA governance solution with network infrastructure management systems to optimize network performance in the EDA. In a large, potentially global EDA like EDICTS, network performance is a real issue, especially because the system could affect regular bank operations if it slows the network down.
Closed loop—The SOA governance loop seen in Figure 8.12 and others represents the concept of a closed-loop SOA governance solution. We recommend that EDICTS utilize a governance solution that enables consistent definition and enforcement of governance policy from design time through runtime. As Web services are developed, and then placed into position at design time, the governance policy that is specified for them should automatically continue with the Web service at runtime. For example, if a Web service requires encryption of an outbound SOAP message, the designer needs to be confident that the encryption policy will be enforced at runtime. The closed loop ensures that this will happen, and also provides an audit log to prove that the encryption is in effect. Closed-loop SOA governance for EDICTS relies on a continuously updated, unified UDDI registry that spans design time and runtime.
This chapter walked us through the application of EDA on an application, enterprise, and cross-enterprise level.
Money laundering, the crime of concealing illicit earnings in legitimate bank accounts, is a worldwide problem affecting many banks. Banks are required to be vigilant in detecting and preventing money laundering, and many of the controls they implement to avoid becoming complicit or liable in this crime involve enterprise information technology.
Detecting money laundering requires banks to be able to observe suspicious patterns of transaction activity, including those that take place between multiple banks and even countries.
Event-driven architecture has the potential to improve a bank’s ability to detect money laundering by seeing and correlating transaction event data from transactions across multiple divisions of the bank, multiple banks, and geographic regions in real time. The EDA can be dynamic enough to allow fraud examiners to establish and modify money-laundering detection parameters in a short cycle time.
In an anti–money laundering EDA, transactional systems within a bank would publish event data into the event cloud, either always or upon request, where it could be processed through rules engines that drive a continuous audit process. ESB would sit at the heart of these event clouds. Suspicious transactions could be flagged for follow-up by antifraud staff, or even referred to law enforcement.
In a broader view, multiple bank event clouds could be harvested by regional or global event listeners and event processors that detect transaction patterns between financial institutions.
Putting such an antilaundering EDA into effect is not a minor undertaking. To succeed, the system would need to factor in the needs and expectations of multiple stakeholders, and achieve buy-in prior to commencing the project. Senior management, for example, would need to commit to the success of such an ambitious concept, especially if it involves integrating with other banks. An antilaundering EDA would also require very close coordination between security professionals, internal audit, and IT.
To work, an antilaundering EDA would need extremely effective, but also efficient, SOA governance. For the level of dynamic connectivity needed between component systems, the antilaundering EDA needs to make governance and control a seamless process. Otherwise, the system will bog down.
Ultimately, an antilaundering EDA needs to be approached as a service-oriented business application (SOBA) within the bank’s ongoing SOA program. If it is positioned as a separate system with its own infrastructure and governance, it would probably become too cumbersome and expensive to run, and it will fail.
1. Mollenkamp, Carrick. “Costs of anti money laundering soar.” The Wall Street Journal, July 9, 2007.
2. Ibid.
3. AP. “Daniel Pearl’s Widow Sues Terrorists’ Bank.” July 18, 2007.
4. Ibid.
5. Mollenkamp, Carrick. “Costs of anti money laundering soar.” The Wall Street Journal, July 9, 2007.
6. Ibid.
7. Seeley, Rich. “SCA and SDO Become SOA Essentials for Banking System.” SearchWebServices.com 4/7/07
8. For more information, visit www.coso.org