Event Driven Validation (EDV)

Event Driven Validation, sometimes referred to as Patrol, is a system in digital banking that will put a end user through a step-up authentication workflow when they attempt a high risk event. The user will go through their configured MFA work flow (Secure Access Code, Token or 3rd Party). If, and only if, they complete that workflow will the action be allowed.

The system is configured around Audit Actions. Almost all activity in digital banking is captured and tied to specific Audit Actions. These are the same Audit Actions you can subscribe to via the Audit Action Extension type.

Patrol vs Patrol+

Q2’s Patrol product is a system that has the ability to configure specific Audit Actions to trigger step up authentication. Patrol and Patrol+ are the two product offerings that Q2 has, both of these products sit ontop of the Event Driven Validation (EDV) system.

There are two modes for this system. The first mode, Patrol, is that those configured audit actions will always trigger step up authentication. There is an optional additional configuration option that will delay re-prompting an end user (by X minutes) for additional MFA within the same session.

The other mode of Patrol is to only trigger this prompt if Q2’s Sentinel product has determined this login is Suspect. This mode allows for a bit my dynamism to the system so that only users with a suspicious login will have to go through the step up workflow. With this mode, we can configure individual audit actions to trigger all the time, or only if Sentinel deeps the session suspicious. This means you could have the UpdateProfile audit action only trigger if suspicious but AddSecureAccessCodeTarget always trigger. In this mode, there is an additional configuration that can say, always block this audit action if the session is suspicious.

As you can see, the standard Patrol product is very flexible to meet the various needs of each of our financial instutitions.

This flexibility is sometimes not enough and our financial instutitions want to connect this system to an external system that might house additional information to be used in the decisioning (To MFA, or not to MFA). For this purpose Q2 built Patrol+. Patrol+ takes the same system built around Audit’s and instead of statically configuring an AuditAction to trigger step up, or rely on the suspicious session decision of Sentinel, it will instead call out to an EDV Adapter. This EDV Adapter can then call out to a 3rd Party API (or make a local decision). This adapter is able to return 1 of 4 results: Allow, Disallow, RequireStepUp, TerminateSession. When using this EDV adapter pattern, there is still a configured list of AuditActions that cause the adapter to be invoked, but the configurations of “only do if suspicious session” or “block if suspect session” are ignored.

EDV Profile

EDV profiles are a group of AuditActions (and associated configuration) that can be applied to Groups. This means that you can have different groups of AuditActions that trigger EDV per group in the Q2 system. Maybe you have a high risk group that will always trigger EDV for all the available audit actions. While you have a more regular group that only triggers when the login is suspect. This means you would have two different EDV Profiles and then you would go into Q2 Console and apply the profile to each Group respectively.

The profile is also where the delay in re-prompting a user in session is stored. As discussed, the system can be configured to delay re-prompting after a successful MFA. This delay (in minutes) can be configured per EDV profile.

Additionally, EDV profiles are where the Patrol vs Patrol+ mode configuration is stored. What this means is that you can have a profile that is operating Patrol mode (static or suspect session only) while another profile is in Patrol+ mode (calling an adapter). This allows for flexibility during testing (only apply Patrol+ profile to test group) or if you want to control API costs to 3rd parties and only have a subset of your user base call the 3rd party for decisioning.

EDV Adapters

Above is the general architecture of the EDV adapter components. It follows the same pattern as all the other adapters. HQ recieves a request and (based on configuration) will make a standard API call to the configured adapter. An SDK extension is shown in the diagram to show where the traditional UUX components fit, but is typically not part of this EDV adapter system.

EDV Adapters will recieve a common set of contextual information for every audit event. In addition to this standard set of information about the session, the EDV adapter will be provided with event specific information in the audit_details. audit_details will vary from one audit action to another. This audit_details will give you information specific to that audit action (like the new SAC target address, if its being called because of the AddSecureAccessCodeTarget audit action).

The EDV adapter’s decide_edv function recieves a EdvRequest object and expects an Enumeration from EdvResult to be returned.