The Challenge
Financial institutions are facing increasingly stricter anti-money laundering (AML) compliance regulations and scrutiny. AML employee training is a critical component to managing a company’s risk. Furthermore, providing employees with sufficient and adequate AML training is often required by law. AML compliance failures can have a far-reaching impact on a company’s bottom line, damage their reputation and effect their share prices. It is crucial that AML training raises employee awareness of these potential costs and teaches employees how to recognize and report suspicious behavior in a proactive manner.
The Design Process.
Initial Research: As this was a concept project, I did not have access to a specific company’s AML policies and procedures. Being the researcher that I am, I turned to the internet. I researched what AML procedures involved, tried to familiarize myself with industry standards and educated myself on industry specific jargon such as KYC (Know Your Customer) and EDD (Enhanced Due Diligences). I also read AML articles, publicly available government AML compliance guidelines and searched for real-life examples of the consequences of AML failures, e.g., fines, negative news coverage, etc.
Through my research, I discovered that AML compliance was a very complex issue involving numerous employees. These employees all had various responsibilities and AML compliance considerations that had to be accounted for. I began to suspect that designing an AML training course would require breaking down a course into modules specifically tailored to each role and scenario.
Consultation with Subject Matter Expert (SME): Once I felt I had a foundational knowledge of what was involved with AML compliance, I scheduled a meeting with a SME with 10 years of experience working in finance. During our meeting, the SME and I discussed a variety of compliance issues and identified a number of pain points related to AML compliance.
We began to focus our attention specifically on account managers. During our discussion, we explored why an account manager would fail to follow proper KYC procedures when onboarding new clients and the company culture that might contribute to this kind of behavior. We explored the proper procedures for handling non-compliance concerns as well as potential compliance reporting pain points. The SME and I also agreed that it was important to raise employees’ awareness of the potential consequences of failing to properly report non-compliance concerns.
Note: There is room in the structure of this module to expand the scenario to incorporate company specific procedures for reporting internal AML non-compliance concerns. However, given the conceptual nature of this project that section of the scenario was not included in the design.
Design Theory:
Inspired by Cathy Moore’s “Map It” approach and influenced by the constructivism learning theory, I decided to design a branching scenario that would place learners in the role of an account manager who is concerned that a teammate is disregarding their company’s AML onboarding procedures.
Branching scenarios put the learner in the center of the action and require them to make decisions based on the information provided. Their decisions shape the outcome of the story and show learners the consequences of their choices. In this way, learners become active participants in the learning experience and research shows that they are more likely to retain what they have learned.
Furthermore, by breaking down AML compliance training into individual modules specifically tailored to certain roles and scenarios, I avoid a data dump situation that can cause learners to disengage from a more traditionally structured course.
This module could be combined with several modules to form a more comprehensive yet still tailored AML training course. Or it could be sent out to account managers as one of a series of targeted activities in a long-term AML refresher program.
Script and Storyboarding: After meeting with the SME, I developed an initial script for the module that laid out the situation, choices and consequences. I color-coded the different decision paths to make it easier to follow.
Next, I had the SME review the script for authenticity. After incorporating the SME’s feedback, I mapped out the branching scenario using the app Twine.
Once I had the logistical aspects of the module finalized. I turned my attention to the visual aspects. I used Adobe XD to create a mock-up of each slide type. Using an iterative design process, I refined each slide layout to balance form with function until I was happy with the overall design. I sourced my images from Adobe Stock and edited them to fit my design needs using Adobe Photoshop.
Development: I developed the final product in Articulate Storyline. Using a combination of triggers, states, layers, variables and conditions I was able to build in the functionality necessary to support the design of this branching scenario.
xAPI Implementation
For this project, I worked with Javascript xAPI code to collect data on my learners’ experiences. This information was collected in my Veracity LRS (learning record store) account for future analysis and supports the module’s design and goals.
User ID: Since this module is not hosted in a Learning Management System (LMS) and the design of this module does not ask learners to input a name or email, I needed a way of identifying individual users so I would be able to track their experience. I was able to code my module to generate a unique, anonymous, random ID for each user. The module will then cache that username, so if the same user returns, they have the same username.
Tracking Answers: Each time a user selects a choice a xAPI statement is generated. Instead of seeing a typical final score and pass rate (standard of SCORM) these statements allow me to track a user’s progress through the scenario and identify which choices are causing the user the most difficulties. This information allows me to better understand a user's thought process and may suggest where additional training or further information is necessary.
Resources Viewed & Duration: An xAPI statement is generated and sent every time a user consults one of the optional resources. The time a user spends on each resource is also recorded. This combined with the answer tracking statements allows me to identify whether or not a user is utilizing resources and how those resources are influencing a user’s choices.
Browser Focus: Utilizing Joe Stueben’s tutorial, I was able to code my module to track when users minimize the module, switch to another window, or switch to another tab. This allows me to identify points in the module where user’s attention may have drifted and can indicate areas of the module where additional engagement may be necessary.
Duration (Module): When a user successfully completes the module, a statement is generated which records the length of time a user spent on the entire module.
Summary: As you can see, my xAPI implementation provides for a far more detailed and robust picture of a learner’s experience than the simple pass/fail user score and time spent data typically captured with SCORM. Using the data collected, I can adjust my module’s design to further improve the learner experience or use the data collected to identify future or additional training needs and opportunities.
