Consider a scenario where Company X would like to buy out Company Y. Let's say company A is the company that is mediating the deal between both companies X and Y. Usually, company A would turn out to be a big investment bank or consultancy firm that deals with Companies X and Y on different projects, in addition to their suppliers and competitors. As a result, employees of Company A can make huge amounts of illegal money if they hear the news about the merger between Company X and Y earlier than the public disclosure. In order to prevent this and prevent any potential lawsuits, companies enforce what is called the Chinese Wall between different departments. This makes sure that information is controlled and compartmentalized between specific departments.All companies need to be very careful to control the flow of information between different departments to make sure that they would not be charged with insider trading by the authorities. This is especially true in the field of investment banking, where such practices are more prevalent and likely to occur.

In spite of all these regulations, a consultant in a company might need to know if any department in his/her company is involved with any other company prior to a deal being struck. Therefore, under these circumstances, there is a need to gather limited information by circumventing the Chinese Wall. Companies get this done by a special software that assesses potential conflicts. If a conflict is found, the senior management needs to choose one business and discard the other. This is the business selection part of the process. Put together, the entire process is called Conflict Assessment and Business Selection, or CABS for short. 

As part of a course offered at UIUC (CS 528), 2 of my group mates and I designed and implemented a simplistic enterprise CABS system from scratch. The application was implemented in Smalltalk, using the SeaSide web framework, on the Pharo IDE. This application gives the highest user privileges to an administrator/admin. The admin would be able to add and remove other users. All users have been classified as either bankers or clearers, to reflect the real-world corporate environment. A banker is the person to initialize a conflict check, while a clearer, or multiple clearers, are the ones to come up with the final result and close the check. The application allows bankers and clearers to talk to each other over a monitored messaging option, which can be monitored by the admin. In terms of design patterns, the admin was implemented as a Singleton pattern. The inter-communication between all entities followed the Mediator pattern, while the status of the check itself followed the Observer pattern.  

The entire code can be found as a Solution (.ST) file on my Github repository

The login window is shown below:

The first time a banker logs on to his/her terminal, there should not be any checks since they haven't issued any yet. The blank banker's terminal is shown below:

The interface to add a new conflict check is shown in the following screenshot:

The bankers' inbox are adding the check is shown below:

As of now, the banker has only initiated the check. He/she has not launched the check to a specific clearer. In the drop-down box, the banker needs to select 'Launch' and then select 'Go'. At this stage, the check has been issued to the respective clearer and the status of the check would be updated to the 'Launched' stage.

At this point, the clearer can see the check in his/her terminal. The check can be issued to multiple clearers at the same time by the banker, or the clearer can pass on the check to another clearer or even to multiple clearers. The clearer's inbox terminal at the point of receiving the check is given below:

It is possible that the team of clearers might need to talk to each other, maybe even with the banker. However, they are forbidden from simply picking up the phone and calling up people because of the aforementioned Chinese Wall. As a result, we have provided for the added functionality of discussion between any number of members. All discussions are logged so that any violation can be immediately picked up by the compliance team and/or the admin. To reach the discussion stage, any one of the clearers need to set the check to the Discussion stage from the drop-down, type in the ID(s) of the banker(s)/clearer(s) to be invited and hit the 'Go' button. A sample discussion is shown below:

 

Lastly, the interface of the commander-in-chief of this application, the administrator. The admin can add or delete members from the system, search for checks and can examine the contents of every discussion that has taken place in the application. Also, checks that haven't had any progress for 3 days are automatically classified as 'Emergent' checks and are highlighted in a separate table. A sample screenshot of the admin screen is shown below: