Parent/child organization - Country & Organization; 3-4 have shared common metrics (shared standard) + 3-4 unique metrics; global collation + child-level drill-down

[edsar]

In order to manage AML operations across countries and organizational groups, a CCO would like to see:

1. Entire bank rolled up (common metrics and an country specific ones)
2. By Countries – Germany, US, Singapore, UK

3.  Have roll up and drill down views

   a. Rolled up dashboard view based on commonly defined metrics that apply to all countries/regions i. Example- Sanctions Screening, KYC/CDD, Training, Periodic Reviews etc. b. User can drill down by metrics and zoom in on countries/regions

4.  Dashboard shows label Global Vs. regional – e.g. in current version it will show

   AML Dashboard – LBBW New York

5.  Have ability to (in settings) to setup/configure the regions in addition to the metrics

6. The dashboard views will based on user role permissions (the CCO of LBBW can see all but regional CCOs can only see theirs etc.)

[krseibel]

Child Dashboard:

[krseibel]

Parent Comparison Top

of the Page:

[krseibel]

Parent Comparison Middle of the Page:

[krseibel]

Parent Comparison bottom of the page:

[krseibel]

Parent Map:

[krseibel]

Email discussion with Rabbani: I think this is the right direction to go with. Few ideas to consider-

· Adding the location name next to the Header (e.g. Dashboard Overview – New York) · On All view – flagging the “common metrics” and displaying them on top and then display location specific metrics on the bottom o Maybe add a Location column and indicate All, New York, Singapore etc.

I think that this just adds more “stuff” to the dashboard but with little payoff. Child-specific metrics will be available on the child-specific dashboard (here, I think it would be a good idea to specify common v. specific), but I’m not sure how the parent benefits from having all of the child specific metrics on their dashboard—are there instances where a parent would really care about child-specific metrics? [yes, parent may care about child specific metrics…try to see if there is way to delineate between common vs child specific…Exec needs to be able to easily visualize what’s what]

Thinking about using the app, I will add a column with location to the data—the column will not be visible from the website (there are already enough indicators on the site to show which location the data is for), but I can make it visible when the data is exported—that way, if one exports all of the child-specific data, it is clear which data belong to each location. [Yes think that will help depending on how its displayed…give it a try and we will evaluate]

o Can we add Sparkline in a column also to show historical trends on completed Yes—this is in the backlog to complete.

· On Settings- o Need to expand the configure metrics to note which location they apply to I think we need to reconsider allowing clients to configure metrics: Allowing clients to change metrics means that they may change them without understanding the ramifications: if we provide update or add access to the CCO, are they always aware of all of the internal SLAs that potentially govern the current settings? [lets add some constraints but think it’s a powerful feature on usability and ease to deploy…given my previous scorecard development projects, here’s what I would recommend- Make a bucket for common metrics that apply to all…perhaps a radio button or check mark to flag if this is a common metric and then give option to add Only Parent user have permission to add common metrics Child user (i.e. NY CCO) can select the applicable common metrics from bullet one Child user can add their regional metrics and choose option to roll up If Yes, the Parent sees them as that Child’s specific metric If no, it’s only can be seen users at that location It makes forecasting difficult. To forecast properly, we need a stable set of data using the same definitions. Without stable definitions, the series essentially becomes a series with exogenous shocks when the metrics are changed—it makes forecasting more difficult because while we can incorporate past exogenous shocks, there would be little from stopping a CCO from changing the definition of what constitutes “green” to capture most of the current in queue capacity.[Forecasting will be tied to productivity and then the historical counts for “Received”…we can do same as above to flag if the metric will be required for Forecasting (as not everything may be required) Not allowing CCOs or their managers to add metrics means that we can bundle the app with consulting services: part of deployment would require a full review of their existing departments with respect to regulatory requirements, SLAs, and client-specific needs. Rabbani—you did this for LBBW—do you think they would have arrived at similar and/or reasonable metrics on their own? [we will plan to offer consulting services part of the implementation plan to help client define these metrics and benchmarks]

If, despite my objection, you wish to proceed with allowing clients to add/update metrics, we can build out separate configuration pages, but I think we need to think carefully about access roles and use first. Who should have access to adding/updating metrics—specific roles within the parent? Specific roles within a child? Both? [See above] What does it mean if we give parents access to child-specific metrics? Do they know the child well enough to accurately add child-specific metrics? I caution against providing add/update access to a child for any of the common metrics—if a child were to change a “common” metric, all other children would either have to follow the new convention, or it would become essentially a child-specific metric and not comparable to other locations. Who exactly in the parent and child should have access?

o Need to note if they are common or location specific metrics I think we can account for this with access roles—otherwise, allowing children to create “common” metrics would mean that all other children would have to be on-board. Allowing the parent location-specific metrics would require that the parent has specific knowledge about the child.

· On User Admin – o Need to tie to locations also § All view by default would have read right to all locations I think we need to consider limiting user admin roles: a role within children should have read/write permissions for users within that child; a parent should have read/write permissions for users within the parent—but, I don’t think we should give the parent read/write permissions for all child users—unless they are truly aware of staff turnover, changes at an analyst level within the children. [We may need to think about Child vs parent level Admin’s] Who should have access to which locations (even for read access)? Do the children have read permissions for other locations, or only their own location (and maybe even the parent roll-up included)? [Children will not have permissions to see Parent but Parent can see children]

[krseibel]

Note--there's a lot that I just added; I'll break apart separate issues if it helps!