Implementation of Stryker® Pay to Minimize Check Fraud and Improve Check Printing Michael Santana González Master of Engineering in Computer Engineering Alfredo Cruz, Ph.D. Electrical & Computer Engineering and Computer Science Department Polytechnic University of Puerto Rico Abstract  The intent of the project, Stryker® Pay, to the bank (which checks should be paid, what is the was to replace the check printing process in amount and the cashier of the check). Stryker®. The application will be capable of Stryker® started in Puerto Rico as a 30 people converting the check information obtained from the corporation. There were less than 20 suppliers and ERP system into a PayBase (off the shelf application only one manufacturing line. Suppliers and some selected by Stryker® to print the checks) system employees were paid using checks. Those checks input file, store the checks data in a database, print were written by hand and signed. the checks for the desired period of time and send the As the company got more products and positive payment information to the bank (CFA suppliers, a different method was needed to reduce process). After successful application the amount of time and work to generate all the implementation Stryker® was able to replace the checks. Using the ERP system, the finance team was plotter printer with a laser jet printer, reducing the able to generate a text file with all the checks needed working area by 50% or more. Also, Stryker was and they will be printed in a plotter printer. This able to reduce the headcount required to execute the alleviated that check run task. task by 50% (from two employees to one) and the Stryker® currently generates a check run thru inclusion of the electronic signature in the check their ERP system and prints all checks in a plotter printing process eliminating the need of a director to printer. A pre-printed paper is bought and used for sign all checks at the end of the run. Finally, the the printing process. After printing all checks, the application reduced the time to execute the process finance personnel will verify that the generated run by more than 80% (from eight hours to one hour). is correct and that the information printed on the Key Terms  CFA, Digital Check Printing, checks is correct. This is all done manually, Electronic Check Signature, Parser, Stryker® Pay. including the signing of the checks. The process to generate the checks is not only INTRODUCTION performed manually, there is no additional control to ensure that the payments are performed correctly. Check Fraud Avoidance (CFA) process is This represent a major gap in check security since commonly used by industry to minimize the any recipient could alter the checks and cash the possibilities of a user creating a new check using the amount without any alerts to Stryker ®. companies account (fraud) and ultimately, stealing The finance and IT group decided that a new money from the company. Another way is to system was needed to minimize check fraud and the manipulate or change the amount written in the system should also alleviate the amount of work checks. In previous years, this was a common issue needed to execute a check run. Using new observed by large companies and the banks decided technologies available, the company wants to reduce to provide some mechanisms to ensure that if a check the amount of people and time needed to execute the was cashed, the company already authorized it. process by half. Finally, the group wants a 99% This task was accomplished by creating a Check reliability that the checks paid are authorized by the Fraud Avoidance (CFA) process. The process company (check fraud only 1%). consists of three steps: generate checks, determine which checks must be paid, send check information CURRENT STRYKER® CHECK GENERATION PROCESS Every month or when needed, Stryker® will execute their check printing process in order to compile, print and review all the checks needed to pay suppliers, consultants, services and other companies. This process is currently executed manually with the aid of the ERP system. In order to provide an adequate solution, process was evaluated closer. The process was divided in four steps: Setup, ERP Check Run Query, Check Printing and Check Review Equipment Setup All checks generated are produced on a plotter printer. The finance personnel must complete a printer setup in order to ensure printing success. The steps followed are: Figure 1  Ink/Pen review or refill - the user must review Check Run Text File Screenshot the status of the ink in order to ensure that it will last the complete run. If the ink is low, pen must Check Printing be replaced/refill before printing process begins. Check printing defines the process of physically  Paper feed and alignment – since the paper is printing the checks in the plotter printer. pre-printed, it comes in rolls and the user must After the query is complete, the file is sent to the feed the paper into the plotter to print all checks. printer and all checks will start to print. The finance User has to put the paper, hold it in place, align employee has to wait until all checks are printed. In it inside the printer and feed a small amount to case that the printer runs out of paper, the user must ensure that the process is correct. execute the equipment setup again and feed  Test run –to ensure a smooth process, before additional paper. Once the printing is complete, the executing the current check run print, a small user has to separate each check manually (plotter test run is conducted by the finance employee. paper comes in rolls and divided in sections; each check was printed on one section and separated ERP Check Run Query afterwards). When the equipment setup is complete, the Check Review finance employee has to determine the scope of the checks to be printed. To accomplish this task, the After separating all checks, the finance emplo- user logins to the ERP system and generate a “check yee has to review and inspect all checks printed. He run query”. The query generates a text file that will verify the following attributes of the check: Pay contains all the check information in sequential to Name, Check Amount and Invoice data. If one of order. Figure 1 shows a section of the check run text this attributes was incorrect, check is destroyed and file content. printing process (from setup to check review) is This process must be done every time a check or repeated. multiple checks are needed. Check Signing com. The sections of the bill cover responsibilities of a public corporation’s board of directors, adds After all checks are printed and reviewed, criminal penalties for certain misconduct, and checks must be signed by the controller or plant required the Securities and Exchange Commission to manager. create regulations to define how public corporations Check Fraud Avoidance Control are to comply with the law. Stryker currently has no CFA process Research on this act is needed to ensure that the implemented. Checks are sent to the supplier and no system to be develop complies with it and minimizes additional verification is performed. If there is a fines or observations during finance audits. Even large discrepancy observed between the month ends though some tasks might be easier to accomplish in expected paid amount and the actual cashed amount, certain manners, the application development must verification is performed with the bank to evaluate ensure that no law or procedure is broken. and determine the corrective action. Process Opportunities Upon deep evaluation of current process, the PROCESS EVALUATION following opportunities were observed. This section covers all the activities performed  Large floor-space occupied by plotter printer to understand the current process and all the – current plotter printer occupies 12sqft area. opportunities associated to it. This does not include the area needed for the ink Regulations and Laws Governing the Process and paper.  Check id’s are given by the pre-printed Stryker® is a Medical Device company paper bought – pre-printed information on regulated by different standards/laws. The Federal checks is expensive and the use if the paper id Drug Administration (FDA) is the government makes it difficult to consolidate/track the checks agency that enforces the Code of Federal generated. Regulations (CFR) for medical device companies.  Difficulty to search and review previews 21 CFR 820 [1] defines the requirements for the checks generated – the only way to look up company’s quality system which includes all information about a check is to print the check automated processes performed. Also, the company run completely and look one by one the checks must comply with ISO 13485 [2] standard, Quality until it is found. Once the file is executed and System Requirements for Medical Device Company, deleted, there is no record of those checks. Also, defined for Medical Devices. This standard also there is no way to modify the checks during the includes all automated processes. Finally, the run. To modify the check, the user must wait company must ensure that their finance process until the run is completed, destroy the check and comply with the Sarbanes and Oxley Act [3]. execute a check run again only for that check. After careful review of all three standards, it is  Lack of Check Fraud Avoidance process to concluded that Sarbanes and Oxley Act is the only ensure check payments are accurate – one that applies to this project. As for any other Stryker® doesn’t have any process for positive development project, regulations and laws must be payment. clearly understood to ensure compliance. For this  Excess Time/Resources spent in process– one project, the Sarbanes-Oxley Acts governs and employee spends all day to execute the process regulates the finance system in a corporation. The and verify the checks. Plant Manager has to sign bill, which contains eleven sections, was enacted as all checks. a reaction to a number of major corporate and  Increased impact in run cost if issue occurs accounting scandals, including Enron and World- during check printing – once the check run starts, it can’t be stopped. If an issue occurs in A new limitation was established with this the middle of the run with the printer or paper, review. Discussions with the ERP system owner the user must start the process again by looking showed that no modifications or connections will be which was the last check printed. performed to the current ERP system and queries. This meant that the new system to be developed As the company gets bigger, it is harder to keep would use the output generated by the current query. track of all the checks generated which creates to The current query generates a text file which additional issues: contains all the checks formatted to fit inside the  Increase in headcount to perform the task. check paper currently bought in rolls. The new  Difficult for plant manager to sign all generated application will take that text file as an input and will checks. collect the required data. This was a clear indication  Possible reconciliation issues that could that a parser was needed. generate an observation during an audit.  Regulation Research: STRYKER® PAY Additional emphasis was given to the Sarbanes In an effort to eliminate the process and Oxley Act. After careful review of the act, it was opportunities observed, Stryker® requested the understood that this process is not governed by the development of a system. The system should achieve Sarbanes and Oxley Act. With this in mind, there are the following general goals: no external regulations that govern this process and  Reduce working area footprint thus all requirements would be established by  Reduce time to execute check printing process Stryker.  Reduce headcount required to execute check  System Limits: printing process An interview was performed to the IT manager  Use new technology available for process to understand the current systems available and what  Include Electronic Signature of Plant Manager where the system requirements for this process. Thru on check printing process. this, the following information was obtained:  Record check data on database  Off the shelf software called PayBase was  Define CFA process and send information to already in house to print the checks securely bank. thru the use of an HP Laser Jet printer - This  Reduce check run errors application only needed a text file containing System Research the checks information in a specific format and delimitation. The requirements were established In order to develop and adequate solution, on their user manual. Software also allowed the additional research in the current process, inclusion of an electronic signature for the regulations and system limits is needed. Also, since checks. the Check Fraud Avoidance is not part of Stryker  PayaBase database must be installed on the current process, research on it was required to same computer where application is running - understand the requirements. Microsoft SQL Server was recommended.  Process Research:  Database must be created in Microsoft SQL Additional research on current process was Server - Since the company already had an performed. Interviews to users and review of the agreement with Microsoft, only Microsoft process was performed during its execution. Thru products could be used. process research, no additional processes, steps or  Computer to run the application must connect activities were found. to the bank thru an FTP connection using a dial- up modem – The bank only allowed push of the CFA file thru an FTP server that could be Convert Check File to Pyabase Data File connected only thru the use of a dial-up connection. Review Check Data  Application must run on Windows 2000 or better. SYS ADMINPrint Checks Report  Check Fraud Avoidance Process: Edit Check Data ACCOUNTS PAYABLE (AP) Check Fraud Avoidance Process requirements Printer are established by the bank. The bank needs specific Print Checks information to determine if a check can be paid or not. After review of their requirements the following Paybase Database MIRC Printer Generate CFA File item must be incorporated:  Application must create a text file containing Transmit CFA File the checks information to be paid. Formatting BANK SYSTEM and information was included in their CFA Figure 2 Use Case Diagram for the CFA Application manual.  Connection to the bank must be done thru a dial- Use Case Scenarios up connection to an FTP server. Each Use Case was defined to understand the  After a check run, file must be created and push needs of the client. A standard Use Case Scenario to the FTP server. The bank will use this file to template was used which contained the Use Case determine if the check can be paid or not based Name, Participating Actors, Entry Condition, Flow on the check number, pay to and check amount of Events, Exit Condition and any other Special information. Requirements. Figure 3 - 5 are examples of the Use All of these items described above will be taken Case generated for this project. into account when developing and designing the application to ensure that it will be functional and take advantage of current items available. The intent is to make sure that all areas of improvement are covered. System Design and Development The first step to develop an application is to fully understand its process. To achieve this, a series of Use Case Scenarios were created that depicted the possible use of the system and the interactions between the users. Each Use Case Scenario will give us valuable information on how the system should be developed and will also allow users to provide feedback on the desired process. The application could be defined by seven (7) general Use Case Scenarios and three actors. Figure 2 shows a UML Use Case Scenario Diagram for this: Figure 3 Convert Check File to Paybase Data File Use Case The following information must be recorded in the database to accomplish the tasks at hand:  CFA File Information– for the CFA file, the bank provided a list of the information required by check. Some of the information required by the bank was: account number, check number, payTo, check amount, flag of check void.  Check Printing Process – the check printing process required additional information that was provided by the PayBase application. Stryker decided to buy a software called PayBase, from Bottomline technologies, that will be used to print all the checks. The application requires as an input a text file containing the checks information. Some of the information for the file Figure 4 are: checks total amount, payTo, check date, Edit Check Data Use Case check invoices amount and others. Database design was simple since the information required was minimal. The only relationship [4] in the database developed was between the checks and the invoices. A check could have multiple invoices but an invoice can only be related to once specific check. For that reason, there is a foreign key on the invoices table pointing to the check in belongs to. Figure 6 is the UML database diagram for the database generated. Figure 5 Generate CFA File (Scenario 1) Use Case Database Design A database diagram was developed to define the information needed to be stored from the check runs. Figure 6 These data will be used to generate the CFA File and Database Design Diagram also to generate the file for the PayBase application. Application Design After evaluation of use case scenarios, a user requirement specification document was generated. The idea was to provide a baseline on what the system must be capable of doing. The user requirement document was completed and signed by all parties involved in this project. This was all the information required to develop the application. The Laser Check Printing is the Solution created in Visual Studio and all classes were developed in C#. It was decided to follow object oriented design [5] to complete the application and ensue that some of the design patterns [6] were applied for proper communication and integration of the different classes. The solution is composed of two different NameSpaces:  Laser Check – Contains all the classes developed to populate the Paybase Database from the Check File, convert the data from the Paybase Database to the CFA File format, Check Printing and all the forms created.  FTPLib – Contains the class used for FTP communications. Some of the classes have dependencies between each other, the LaserCheckApp class uses the CheckConversion class (see Figure 7 for details). The CheckConversion class is a static class and thus can be used by anyone without the need of instantiation. This is one of the cores of the application since it will take the Check File and parse it to generate the PayBase input file for check printing. Since this is just a tool, it was decided to create this class as static and thus there is no need to create a new instance of the object. At the same time, the CheckConversion class owns an instance of the Check class as shown in Figure 7 and thus an aggregation connection is created. This class will read each line of the check text file and parse its content. It will collect the required data from each line while detecting when a new check or invoice starts. Since a check could contain multiple invoices, special rules were created to Figure 7 Class Diagram: LaserCheckApp with CheckConvertion detect when a check started and ended. The other core part of this application is the A second tab is available which allows the user CFAFileGenerator (see Figure 8). This is a form that to create the CFA File. This is achieved by using shows all the checks available in the database and both classes: GenerateCFAFile static class and the also allows the user to edit the data. The data is ChecksData class as shown in Figure 9. The Checks- obtained by using the ChecksData object. Data class provides a connection to the checks database and the GenerateCFAFile will take that data and create a new text file with the needed format for the bank. Figure 9 Class Diagram: GenerateCFA with ChecksData The LaserCheckApp has a UserPass Object and thus and aggregation was created between them. The UserPass class also has an aggregation to the FTPFactory which is used to communicate with the bank using FTP communications. The diagram in Figure 10 shows the interconnections between each classes. The class diagrams where generated to understand how the different classes will interact and to ensure that the connections defined inside each one were adequate. This should ensure proper Figure 8 transfer of data and actions between objects. Class Diagram: LaserCheckApp with CFAFileGenerator Application user interface is simple in order to minimize errors by the user.  Home Screen – Contains the three main buttons of this application. Figure 11 shows how the home screen looks like. Figure 11 Home Screen  Checks Data – Provide graphical view of the checks generated and allows the user to flag the checks that should not be paid (see Figure 12). In this same window, the user can select the date range for the CFA File and generate it for the bank (see Figure 13). Figure 12 Figure 10 Checks Data Window Class Diagram: LaserCheckApp with UserPass  The time required to execute a check run was reduced to 1hr in average depending on the quantity of checks to be printed  Personnel to execute a check run was reduced to one.  Check printing and CFA file process showed a Figure 13 reliability of 99.99%. CFA File Generator Window  FTP Login – simple window that requires the SUMMARY user to input the username and password for the This paper presented the process to develop the bank FTP server (see Figure 14). This way, only Stryker® Pay application. During this process we authorize personnel can connect to the server. understood the requirements to establish a new electronic check printing system and the processes involved to minimize the possibilities of fraud. We also go the opportunity to increase the efficiencies of the company by reducing the headcount required to execute the task, the time needed and the floor-space allocated. System provided a robust process to print checks while alleviating the need of additional headcounts as the company keeps growing. Figure 14 FTP Login Window REFERENCES System Review and Verification [1] FDA (2015, April). Title 21, Chapter I, Subchapter H, Part 820 – Quality System Regulation [Online]. Available: As with any other system, before production use https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfCFR/ the system was tested to ensure compliance with all CFRSearch.cfm?CFRPart=820. requirements and that all user requirements were [2] International Organization for Standardization (2003). ‘ISO met. 13485:2003 - Medical devices -Quality management Computer with application installed was setup systems - Requirements for regulatory purposes [Online]. Available: http://www.iso.org/iso/catalogue_detail?cs and more than fifty check runs were used on the number=36786. system. The application was capable of parsing thru [3] US Senate (2002). Sarbanes-Oxley Act 2002. [Online]. the text file, generate the PayBase system file, Available: http://www.soxlaw.com. generate the CFA file for the bank and push the file [4] S. Bagui and R. Earp, Database Design Using Entity- to the FTP. Confirmation from the bank was Relationship Diagrams, 1st ed. FL, USA: Taylor and obtained indicating that the CFA file was uploaded Francis Group, 2004. correctly and that the data inside was correct. [5] M. Weisfeld, The Object Oriented Though Process, 4th ed. System Implementation IN, USA: Addison-Wesley, 2013. [6] C. Hortsmann, The Object-Oriented Design and Patterns, System was implemented at Stryker on 2nd ed. NJ, USA: John Wiley & Sons, 2006. November 2015. A total of ten check runs were performed between November and January. No major bugs or failures were observed during that time. The following results were obtained:  The working area was reduced to 9 square feet.