Scope of Work

Decision Engine Project

April 28, 2023

INDEX
INDEX________________________________________________________2
1 DOCUMENT VERSION CONTROL______________________________________4
2 ABBREVIATIONS________________________________________________5
3 PROJECT OVERVIEW_____________________________________________6
3.1 Scope Overview________________________________________________6
3.2 EBU Credit Scoring Project - Project Outputs__________________________7
3.3 Objectives of the Current Project ___________________________________8
3.4 Nature of the Current Project______________________________________8
4 WORKSHOPS__________________________________________________9
4.1 Proposed Workshops & Agenda____________________________________9
4.2 Workshop Assumptions_________________________________________10
4.3 Deliverables & ‘New BRSD’ Document Structure______________________11
5 STREAM 1: STRATEGYONE LICENSING AND CONFIGURATION_________________13
5.1 Scope of Work & Project Activities_________________________________13
5.2 StrategyOne Product Overview____________________________________14
5.2.1 StrategyOne Product Overview____________________________________14
5.2.1 StrategyOne License to stc________________________________________15
5.3 Stream Deliverables____________________________________________15
5.4 Assumptions__________________________________________________16
6 STREAM 2: INTEGRATION LAYER____________________________________18
6.1 Scope of Work & Project Activities_________________________________18
6.2 Solution Overview______________________________________________19
6.2.1 Operational Tool________________________________________________21
6.3 Stream Deliverables____________________________________________22
6.4 Assumptions__________________________________________________22
7 PROJECT PLANNING____________________________________________24
7.1 Project Management Approach____________________________________24
7.2 Project Mobilization and Initial Assessment__________________________25
7.3 Project Organization____________________________________________25
7.3.1 Guiding Principles_______________________________________________25
7.3.2 Team Organization______________________________________________25
7.4 Project Deliverables____________________________________________26
7.5 Project Plan (Timelines)_________________________________________26
8 ANNEXURES__________________________________________________28
8.1 StrategyOne Product____________________________________________28
8.1.1 Overview_____________________________________________________28
8.1.2 StrategyOne Modules: Engine and Designer__________________________28
8.1.3 Features and Benefits of Adopting StrategyOne________________________29
8.2 StrategyOne Technical Requirements_______________________________30
8.3 Integration Layer Technical Requirements___________________________34
8.3.1 Software______________________________________________________34
8.3.2 Hardware_____________________________________________________34
8.3.3 Environments__________________________________________________34
8.3.4 Sizing and Performance__________________________________________35

Materiale per uso interno. 2 di 34

È vietata la riproduzione.
 1 Document Version Control

Version Version
Version Description Author
Number Date
1.0 13/12/2022 First SOW shared CRIF
Updated SOW:
- Revised content and restructured the
document
2.0 06/02/2023 CRIF
- Incorporates vendor responses to stc
queries (business and technical), where
applicable
Updated SOW:
- Added details about DEVELOPMENT &
3.0 08/02/2023 TEST environments CRIF
- Updated System Requirements in
Section 7.2
Updated SOW:
- Replied to comments from stc
4.0 20/02/2023 CRIF
- Made necessary modifications as
required
Updated SOW:
- Added comments for requirement
5.0 14/04/2023 gathering and preparing BRD in Section CRIF
3.1 to cater to STC needs
- Added 1 assumption
Update SOW:
- Update comments for requirement
5.1 16/04/2023 gathering and preparing BRSD in Section STC
3.1
- Remove assumption
Updated SOW:
- Edited Section 3.1 regarding the
requirement gathering and preparing the
BRSD
6.0 28/04/2023 CRIF
- Introduced Section 4 covering detail
agenda for End to End Requirement and
BRSD, SDD & User Stories preparation
- Added Assumption

3
 2 Abbreviations

Abbreviation Definition
CRIF CRIF (vendor)
Bayan Bayan Credit Bureau (vendor)
B2B Business Information Data
B2C Credit Payments Data
EBU Enterprise Business Unit
FDA Fast Data Access
UAT User Acceptance Test
PROD Production (environment)
PRE-PROD Pre-Production (environment)
DR Disaster Recovery (environment)
CRM Customer Relationship Management (system)
JSON JavaScript Object Notation (file type)
XML Extensible Markup Language (file type)
DB Database
JDBC Java Database Connectivity

4
 3 Project Overview

3.1 Scope Overview

Saudi Telecom Company (“stc”) enterprise business unit (“EBU”) is looking to embark on a
transformation journey on how their originations, customer management, and collections
processes are executed by leveraging advanced analytics, segmentation, and automation.

CRIF and Bayan Credit Bureau (“Vendors”) were engaged in December 2019 with a project titled
“EBU Credit Scoring Project” with a project scope of conducting:
1) Gap analysis on stc originations, customer management, and collections processes from a
credit risk point of view
2) Develop bespoke, statistical credit scorecards leveraging internal stc data and external
data from Bayan Credit Bureau
3) Design decisioning strategies and an operational tool to support the ability of stc internal
teams to leverage the credit scorecards within their business processes

Following the initial scope of the project, the scope of the new project is implementing the
outcomes of the previous project. Thus, all the documentation produced as a result of the initial
project form the inputs and business requirements for this new scope.

More specifically, the scope of the new project includes:

 Licensing of StrategyOne, CRIF’s decision engine purpose built for hosting and execution
of scorecards and decisioning strategies
 Configuration of project outcomes (scorecards and decisioning strategies) within
StrategyOne
 Development of an event producer module that will host a procedure to push data
received from stc to an integration layer (also developed as part of this project) that
receives data from stc, transforms data, integrates with StrategyOne, and sends back
data back to stc systems

The project is divided into two streams:

 Stream 1: StrategyOne Licensing and Configuration – is detailed in Section 5
 Stream 2: Integration Layer – is detailed in Section 6

To support the two streams above:

 CRIF, with support of STC, will prepare and document a BRSD for this project (“New
BRSD”) as per CRIF format. However, the BRD resulted from previous project, based on
which the SOW was created, and contract was signed with STC will not be changed and
will be used AS-IS as part of this new BRSD/while preparing this new BRSD.
 This New BRSD, however, will include some more details covering S1 inputs and outputs
mainly.
 Workshops will be the means to gather the needed information and create the New BRSD.

5
  Based on the number of anticipated workshops, CRIF will only be responsible for
documenting the requirements and creating the New BRSD.
 After CRIF submits the BRSD, STC will review the complete document and provide their
comments. On this basis, CRIF will update the document. STC will review the revised
document and provide a sign-off.
 Once the BRSD is signed off, CRIF and STC IT will work on creating the SDD to include all
relevant IT & architecture related details.
 CRIF will also document the user stories in the format provided by STC.

Supporting details for the workshops including proposed agenda, length, and order are provided
in Section 4.

Sections 3.2 and 3.3 provide a wider context by providing more details about the deliverables
from the previous project and the business objectives expected at the end of this project.

3.2 EBU Credit Scoring Project - Project Outputs

As part of the previous project, CRIF and Bayan Credit Bureau delivered the following
deliverables that are related to the scope of this new project:
1) Specifications for six credit scorecards
a. x1 Originations scorecard – calculated for select new and modified orders for select
customers at the time of order placement, calculated in real-time
b. x1 Behavioral scorecard – calculated for select customers with no delinquencies in
batch mode on a monthly basis
c. x2 Collections scorecards – calculated for select customers with delinquencies in
batch mode on a monthly basis / at the end of the billing cycle
d. x2 Scorecard built based on Bayan data
i. x1 Scorecard built on Bayan credit data (B2C data) – calculated for new
customers to stc at the time of order placement, calculated in real-time
ii. x2 Scorecard built on Bayan non-credit data (B2B data) – calculated for
select customers with credit exposure with banks and other financial
institutions in batch mode on a monthly basis / at the end of the billing
cycle
2) Specifications for three decisioning strategies
a. Originations decisioning strategy – that uses the Originations scorecard and Bayan
B2B scorecard, and outputs scores, risk levels, customer profile, recommended
actions, and indicators
b. Customer Management decisioning strategy – that uses the Behavioral scorecard
and the Bayan B2C scorecard, and outputs scores, risk levels, customer profile,
recommended actions, and indicators
c. Collections decisioning strategy – that uses the Collections scorecards and the
Bayan B2C scorecard, and outputs scores, risk levels, customer profile,
recommended actions, and indicators
3) Specifications for report and list generation (“operational tool”) for each decisioning
strategy
a. Originations report and list generation specifications
b. Customer Management report and list generation specifications
c. Collections report and list generation specifications

6
 All project deliverables are functional documentation (business requirement specification
documents). These documents are designed to support the implementation of the above-
mentioned deliverables.

3.3 Objectives of the Current Project

As mentioned in an earlier section, the scope of the new project is implementing the outcomes of
the previous project.

By the end of this project, the objective is to operationalize the scorecards, decisioning
strategies, and operational tool. This means that the calculated scores, risk levels, customer
profile, recommended actions, and indicators are made available to the various stc team to
support them in undertaking their roles.

As such, these are meant to guide and support existing processes, and not to re-design
processes around them.

3.4 Nature of the Current Project

The nature of this project is a software implementation project that will introduce a new software
solution (StrategyOne decision engine) into stc’ s environment as a backend tool and an
integration layer to facilitate data management and transformation between stc’s systems and
the decision engine.

A portion of the implementation will be done in the StrategyOne decision engine and in the
integration layer, which is the responsibility of the vendor. However, a portion must be
implemented in stc systems and tools. These will be detailed in later sections.

No new business requirements are expected to be gathered; these have already been defined as
part of the previous project scope and are documented as part of that project’s deliverables.

7
 4 Workshops

4.1 Proposed Workshops & Agenda

The tables below show the proposed workshops and the agenda points to be covered during each
workshop, broken down into four different workshop groups.

Group No. 1 Topic Overview

No. Workshop Title & Description Length

Project Overview
1-1.5
1 Overview of the credit scoring project and the link between that
hours
project and the decision engine project (this project)

Group No. 2 Topic End-to-End Business Process

No. Workshop Title & Description Length

Originations Use Case (Online Process) – End-to-End Business
Processes
 The originations team’s business goals
 The originations end-to-end business process 2
2
 Existing systems that will be impacted hours

Assumed all teams involved in the originations process are together in

one session
Originations Use Case (Online Process) – Changes to Existing
Business Processes
 How the outputs of the strategy will need to be used by the
teams
1.5
3  How the outputs of the strategy will be displayed on the
hours
system

Assumed all teams involved in the originations process are together in

one session
Customer Management Use Cases (Batch Process)– End-to-
End Business Processes & Changes to Existing Business
Processes
 The business goals of the one of the teams involved in
managing the existing customer base
 The end-to-end business process followed
4 2.5-3
 Existing systems that will be impacted
(a, b, hours (per
 How the outputs of the strategy will need to be used by the
c, d) team)
teams
 How the outputs of the strategy will be displayed on the
system

Assumed four teams (team a, b, c, d) – each with a separate

workshop
5 Collections Use Case (Batch Process) – End-to-End Business 1.5
Processes hours
 The collections team’s business goals
 The collections end-to-end business process
 Existing systems that will be impacted

8
 Assumed all teams involved in the collections process are together in
one session
Collections Use Case (Batch Process) – Changes to Existing
Business Processes
 How the outputs of the strategy will need to be used by the
teams
1.5
6  How the outputs of the strategy will be displayed on the
hours
system

Assumed all teams involved in the collections process are together in

one session

Group No. 3 Topic Input Data Preparation & System Integration

No. Workshop Title & Description Length

General Data Dictionary Changes
 Changes to the stc data model (used in the credit scoring
2
7 project)
hours
 Mapping the old data dictionary to the new data dictionary,
including any transformation logic
Online Process – Integration and Input Preparation
 Integration method with StrategyOne 8
8  Input file preparation and creation hours
 Internal data sources (systems, APIs, databases, and tables) ( full day)
 External data sources (systems, APIs, databases, and tables)
Batch Processes – Integration and Input Preparation
 Integration / data access / data sharing method 8
9  Input files preparation hours
 Internal data sources (systems, APIs, databases, and tables) ( full day)
 External data sources (systems, APIs, databases, and tables)
Event Producer
 The integration of the event producer with Kafka for the online
1
10 process
hour
 The integration of the event producer with Kafka for the batch
processes

Group No. 4 Topic Output Data & Data Management

No. Workshop Title & Description Length

Online Process – Output Data Management
 Table design 3
11
 Data storage and procedures hours
 Data storage / upload / availability in specific systems
Batch Processes – Output Data Management
 Table design 3
12
 Data storage and procedures hours
 Data storage / upload / availability in specific systems

4.2 Workshop Assumptions

9
  It is anticipated that CRIF will need 12 workshops to gather & document the new BRSD
requirements.
 It is expected that that the agendas of the proposed 12 workshops cover all requirements
that STC expect to be covered.
 The agenda for these workshops are to be agreed jointly between CRIF and STC up front.
 STC TE will decide whom to involve in these workshops and will ensure their participation
during these workshops. It is recommended that CRIF and STC TE discuss the workshops
agenda and the attendees of each workshop before scheduling the workshop to ensure
the correct audience and maximum effectiveness.
 CRIF will take a maximum of 2 weeks to prepare and share the new BRSD.
 STC will review the new BRSD document and provide their comments in a maximum of 2
review cycles.
 STC to sign off new BRSD within a maximum of 2 weeks.
 The total duration of the workshops process is expected as 2 weeks.
 For any change in scope arising after the approval of this SOW, it will be managed via the
change management process.
 For workshops 2 and 3, it is assumed that all teams involved in the originations process
are together in one session
 For workshops 4, this will be broken down into 4 workshops (4a, 4b, 4c, 4d) where it is
assumed that requirements will need to be gathered from 4 teams
 For workshops 5 and 6, it is assumed that all teams involved in the collections process are
together in one session

4.3 Deliverables & ‘New BRSD’ Document Structure

The deliverables of this stream are:

 An updated BRSD (“New BRSD”) capturing all the business requirements – Created in
CRIF’s format
 User Stories Documentation – Created in stc’s format
 Software Design Document (“SDD”) – Created in stc’s format

For the New BRSD, CRIF proposes the following high level structure:
 The document will be organized by process (Online, Batch)
 For each of the online and batch process, the following structure will be followed:
o Business Goals
o Current end-to-end business process
o Impact / changes to be made on systems and screens, including how the end
users will make use of it
o Integration to retrieve / receive input data
o Internal input data sources
o External input data sources
o Input file preparation
o Output file structure
o Output file data storage and management

Supporting details for the New BRSD:

 For the batch process, the:

10
 o There are common requirements between the Customer Management use case and
Collections use case – these will be captured jointly (for example, the input data
sources are expected to be the same)
o There are requirements that differ between the Customer Management use case
and Collections use case – these will be captured separately (for example, the
business goals are different between Customer Management and Collections)
 There are some common requirements across all process (for example, the general data
dictionary changes) – these will be captured in a common section across all processes
 For the customer management use case, there are requirements that differ for each of the
teams (assumed 4) – these will be captured separately (for example, the business goals,
current end-to-end business process, and impact / changes to be made are different for
each team)

11
 5 Stream 1: StrategyOne Licensing and
Configuration

5.1 Scope of Work & Project Activities

The scope of the StrategyOne stream is summarized as the configuration of project outcomes
(scorecards and decisioning strategies) within StrategyOne. The configuration is limited to:
 The originations scorecard and strategy – an online / real time process
 The behavioral scorecard and customer management strategy – a batch process
 The collections scorecards and strategy – a batch process
 The Bayan B2B scorecard, embedded within the originations strategy
 The Bayan B2C scorecard, embedded within the above batch processes

The term ‘strategy’ will include implementing all that is needed to provide the score, risk levels,
customer profile, recommended actions, and indicators that can then be ingested by the various
stc systems.

The scope of this project is limited to the implementation of the above within StrategyOne.
However, stc will be able to use StrategyOne for all other business requirements of credit and
non-credit EBU teams as part of the same license. An overview of StrategyOne is provided in
Section 5.2, and a more detailed product description is provided in Section 8.1, while the
technical requirements are provided in Section 8.2.

The following are the activities for this stream:

ITEM RESPONSIBILITY
Ingestion of the business requirements specification documents by Vendors
the vendor team (outputs of the EBU Credit Scoring Project)
Initial overall solution design and the split of implementation Vendors
between: configuration in StrategyOne by the vendor,
implementation in the integration layer (Stream 2) by the vendor,
and implementation in other stc systems by stc
Holding business and technical workshops with stc to go over: Vendors, with stc
 Hardware requirements and software requirements for support
StrategyOne installation
 Split of implementation responsibilities
 Definition of the integration points between stc systems and
StrategyOne
 Detailed implementation requirements (for stc to implement)
 Impact on processes and systems
 Data samples requirements (for testing) and any changes in
data format domains
Creation of final StrategyOne detailed design documentation (SDD) Vendors
Configuration within StrategyOne of the identified scope Vendors
Creation of testing documentation Vendors

12
 Internal testing of all configuration and making the necessary fixes Vendors
Creation of final deployed package Vendors
Development of integrations between stc systems and StrategyOne stc
Creation / development of input files for ingestion by StrategyOne stc
Data samples provision stc
Test Case Provision for User Acceptance Test stc
Conducting User Acceptance Test (stc IT / business teams) stc, with vendor support
Conducting the necessary fixes based on User Acceptance Test Vendors
findings
Setup of the environments (DEVELOPMENT, TEST, PRE-PROD, stc, with vendor support
PROD, DR) including hardware and software procurement
Installation of StrategyOne in various stc environments Vendors, with stc
(DEVELOPMENT, TEST) support
Installation of StrategyOne in various stc environments (PRE-PROD, stc, with vendor support
PROD, DR)
Deployment of the final strategy into the various stc environments stc, with vendor support
(DEVELOPMENT, TEST, PRE-PROD, PROD, DR)
Conducting System Integration tests vendor, with stc support
Conducting handover and knowledge transfer to stc teams Vendors
Conducting technical training and training on the StrategyOne and Vendors
designer (3-5 days)

5.2 StrategyOne Product Overview

5.2.1 StrategyOne Product Overview

StrategyOne, the CRIF solution for strategic decision management, is a software tool that can
manage and automate the entire decision making processes of an organization covering both its
credit related and non-credit related needs, across the customer lifecycle (engagement,
originations, customer management, collections) in real time or batch mode.

StrategyOne centralizes the definition, storage, and application of the all rules, scoring models,
and decisioning logic used in business operations to provide users with greater automation, more
responsiveness to change, and less expensive distribution and maintenance of their decisioning
processes.

StrategyOne is made up of two linked software modules: the Designer Module and the Engine
Module. The Designer Module allows the Business User to design, create, manage, test, and
control all the elements of the decisioning process (e.g. rules, scoring models, segmentation,
actions, etc.) in a user friendly way through a graphical user interface. The Engine Module is the
module that operates in the live environment, where it received input data for each decisioning
process from one of the existing systems of the organization, processes the input data as per the
defined elements (designed using the Designer Module), and generates the outputs. The output
is sent back to the system.

See Section 8.1 for StrategyOne decision engine product description.

13
See Section 8.2 for StrategyOne technical requirements.

5.2.1 StrategyOne License to stc

As part of this project, the vendor is providing stc with StrategyOne license covering:
 StrategyOne version 7 – the latest release version of StrategyOne
 A perpetual software license covering
o The Engine Module
o The Designer Module
 Annual maintenance contract for a contract length of five years
 Installation on stc environment
 No license restrictions on number of users, volumes of data and transactions, or number
of servers.
 Limited for the stc Enterprise Business Unit across all teams. Use by other units (e.g.
Consumer Business Unit, etc.) or other subsidiaries / organizations requires a license
extension and a notification to the vendors.
 The use of StrategyOne under all above options presented is limited for the Kingdom of
Saudi Arabia only. Use by other stc subsidiaries / partners outside of Saudi Arabia (e.g.
stc Bahrain, etc.) requires a license extension and a notification to the vendors.

5.3 Stream Deliverables

The deliverables of this stream are:

 StrategyOne Software
o Installation files for Engine Module
o Installation files for Designer Module
 StrategyOne product documents
o StrategyOne product description documents
o StrategyOne system requirements documents
o StrategyOne installation and administration guide documents
o StrategyOne user guide documents2
 StrategyOne detailed specification documentation 1,2
o Project scope document
o Input-Output layout for data exchange
o Configuration document providing details of all that is configured in StrategyOne
as part of the project scope
 Strategies1,2
o Configured strategies (final deployed versions)
 Others1,2
o StrategyOne test cases document
o StrategyOne test input files
o Log of raised testing issues
o StrategyOne training (3-5 days training that covers StrategyOne features,
including configuration using different objects, testing, process deployment) will

1
These are multiple documents for Originations, Customer Management, and Collections
2
The exact documents listed are the standard documents created for StrategyOne projects. Given the documentation
from the existing project, some of these documents may not need to be created or could be created much shorter.

14
 allow stc users to be independent from the vendors in managing future updates to
the processes. The training will also enable client users to transfer the knowledge
internally for other users to be able to use the different StrategyOne
functionalities.

5.4 Assumptions

Assumptions:
 Only the outcomes of the existing EBU Credit Scoring project are included within the
scope of this project; namely:
o Three processes; one real time (originations strategy) and two batch (customer
management and collections strategies)
o Four stc scorecards (originations, behavioral, collections 1, collections 2)
o Two Bayan scorecards (B2B, B2C)
 For the originations strategies, in production, stc is responsible for the creation of the
input files from the source system (CRM) or any other system (as long as it is in line with
the input format and structure agreed upon during initial configuration) and send it to and
receive it back from StrategyOne.
 StrategyOne will send and receive data in the JSON file format.
 Across all processes, the application developed is sized to process as many as 1 million
records in month (based on projection). Revised sizing will be conducted during the
project assessment to account for current and future needs more accurately.
 Derivation of additional variables (new variables create using raw data) will be done by
considering fixed set of fields received.
 Derivation of additional variables is limited to the needs of the EBU Credit Scoring project
outcomes. No additional derivation is in scope.
 stc will provide the data samples for development and testing for all processes in line with
the data structure and format defined by the vendor.
 The handoff point for StrategyOne output of the Processed Requests would be Kafka
 Configuration of additional requirements beyond the outcomes of the existing EBU Credit
Scoring project is not in scope. StrategyOne enables stc to configure additional strategies
within it, which can be done by raising a new project scope with the vendor or done
independently by stc with the StrategyOne designer module (configuration know-how will
be part of the training and knowledge transfer activities).
 Any analysis, design, or implementation of project outcomes within stc systems is out of
scope (e.g. no design of CRM screens, no implementation of screens, etc.) of this project
and is the responsibility of stc.
 stc can manage any future updates and changes to the project processes within
StrategyOne Designer module, as well as creating new processes to use in live
environment.
 StrategyOne will not save any of the processed data. All processed data will be shared
back with stc system with some data temporarily saved within a persistency layer. See
stream 2 for details.
 Integration and any customization on any third-party systems is out of scope.
 The configuration and impact assessment for integration on third party systems is out of
scope.

Assumptions related to hardware / software:

15
  All hardware infrastructure and third-party software (e.g., MS SQL, WebSphere, Windows
OS, Load Balancer, etc.) are procured and installed by stc before the vendor starts the
installation of StrategyOne into stc infrastructure.

Other assumptions:
 stc shall provide a subject matter expert on their IT systems / infrastructure / data to
support in those activities.
 No travel expenses are considered or estimated. Due to the coronavirus situation, all
project activities and deliverables will take place remotely. If travel is required, it will be
billed on actuals.

16
 6 Stream 2: Integration Layer

6.1 Scope of Work & Project Activities

The scope of the integration layer stream is: For batch processes (customer management,
collections):
 The development of an integration layer that sits between stc systems and StrategyOne
and that:
o Ingests data from stc systems in batch on a pre-determined frequency
o Structures and transforms the data in line with the StrategyOne processes input
layout and send the data to StrategyOne
o Receives data from StrategyOne processes in line with the output layout
o Sends back StrategyOne responses
 The development of an Event Producer that receives StrategyOne outputs / log files and
sends them back to stc systems through Kafka

For the online process (originations): the development of an event producer that receives
StrategyOne outputs / log files and sends them back to stc systems through KAFKA

The scope of this stream is to complement Stream 1. As such, only the following is in scope of
implementation:
 The originations scorecard and strategy – an online / real time process
 The behavioural scorecard and customer management strategy – a batch process
 The collections scorecards and strategy – a batch process
 The Bayan B2B scorecard, embedded within the originations strategy
 The Bayan B2C scorecard, embedded within the above batch processes

The more detailed view of the proposed solution for this stream is presented in Section 6.2.

The following are the activities for this stream:

ITEM RESPONSIBILITY
Initial overall solution design and the split of implementation Vendors
between: configuration in StrategyOne by the vendor,
implementation in the integration layer (Stream 2) by the
vendor, and implementation in other stc systems by stc
Holding business and technical workshops with stc to go over: Vendors, with stc support
 Hardware requirements and software requirements
 Split of implementation responsibilities
 Definition of the integration points between stc systems
and the integration layer
 Detailed implementation requirements (for stc to
implement)
 Detailed technical requirements and how the integration
layer will fit into stc architecture.
 Impact on processes and systems
 Data samples requirements (for testing) and any changes

17
 in data format domains
 Operational tool implementation

Creation of final detailed technical specification documentation Vendors

Development of the integration layer, including the event Vendors
producers
Creation of testing documentation Vendors
Internal testing of all configuration and making the necessary Vendors
fixes
End to end testing of the integration layer and StrategyOne, and Vendors
making the necessary fixes
Creation of final deployed package Vendors
Development of data extraction and provision procedures, and stc
the creation of input files for ingestion by the integration layer
(Only for batch processes)
Data samples provision stc
Test Case Provision for User Acceptance Test stc
Conducting User Acceptance Test (stc IT / business teams) stc, with vendor support
Conducting the necessary fixes based on User Acceptance Test Vendors
findings
Setup of the environments (DEVELOPMENT, TEST, PRE-PROD, stc, with vendor support
PROD, DR) including hardware and software procurement
Package deployment in various stc environments Vendors, with stc support
(DEVELOPMENT, TEST)
Package deployment in various stc environments (PRE-PROD, stc, with vendor support
PROD, DR)
Conducting System Integration tests stc, with vendor support
Conducting handover and knowledge transfer to stc teams Vendors

6.2 Solution Overview

This section describes the integration layer and how it works with StrategyOne (detailed in
Stream 1). The solution comprises of a customized integration Layer with the StrategyOne
decision engine embedded within. Details follow:

For the two batch processes (customer management, collections):

 On a predetermined frequency, stc systems will share multiple CSV file containing the
required data in a predetermined format
o For the customer management process: conducted monthly
o For the collections process: one day after each billing cycle
o stc can amend the frequency later on based on business requirements
o stc will need to run the procedure automatically to extract the needed data and
provide it in the predetermined format
 The customized integration layer will retrieve this data, perform data transformation, and
create JSON input file
 The JSON files will be sent to and ingested by StrategyOne, where the batch engine
container will execute the processes and generate response batch output

18
  After the successful execution, the Event Producer will read these response files and
compile request in an Asynchronous routine and push these to KAFKA.
 stc will ingest these files into a DB / FDA for further processing.
 After the successful execution, the outputs of the batch are stored for future use. At any
given time, the outputs of the most recent two batches executed are stored. Upon
executing a new batch, the outputs of the newly executed batch will be saved and the
outputs of the oldest batch will be removed. This occurs on a rolling basis.

The diagram below shows the high-level architecture for the batch processing, with an indication
of the responsibility breakdown between stc and the vendors (CRIF).

For the online / real-time process (originations):

 For specific orders that meet certain criteria made on the CRM, the CRM system will send
the required variables in a predetermined structure in JSON format to StrategyOne
through the exposed API
o Before sending the data, the needed data (stc data collected on screen, historical
stc data from other systems / DB / FDA, and Bayan B2B data) will be retrieved,
transformed (where needed), and an input file will be created
 StrategyOne will execute the process and generate the response file
 After the successful execution, the response file will be returned to the source system in
real time
 The output response file is also stored as logs/outputs in a specified directory.
 The Event Producer will read these Response Files (stored as logs/outputs in a specified
directory) and compile request in an asynchronous routine to push these to KAFKA
 At any given time, all outputs of the latest two months are stored. The Purging Frequency
of the Outputs can be discussed and agreed with stc.

The diagram below shows the high-level architecture for online / real-time processing, with an
indication of the responsibility breakdown between stc and the vendors (CRIF).

19
A high level description of the event producer module which will be applicable for both online /
real time and batch processing is as follows:

 After the execution of strategies / processes configured (scorecards, etc.) in StrategyOne,

logs/output files (xml) will be stored in a specific directory on StrategyOne server
 The module will access log directory and access the logs/output
 A procedure will be scheduled to at a defined frequency where it will be pinging the logs
folder continuously
 After each execution, the logs/output will be loaded into the module
 An event will be created hereafter, in order to be sent to the Kafka event broker
 Considering the event producer as the Source Data of Kafka, it will be integrated with the
Kafka connecter and push data to Kafka
 The transaction will end after the response lands on Kafka and there will not be a success
message passed from Kafka
 The integration could be done by either:
o Standard Kafka’s API
o Using JDBC Connector for Kafka Connect
o Using log-based Change Data Capture (CDC) tool to integrate with Kafka connect.
 This module would be designed to push data to Kafka in an asynchronous manner

See Section 8.2 for StrategyOne technical requirements.

See Section 8.3 for integration layer technical requirements.

6.2.1 Operational Tool

As detailed in Section 3.2, one of the deliverables of the previous project is documentation
related to the ‘Operational Tool’ – which are specifications for report and list generation for each
decisioning strategy (originations, customer management, collections).

The implementation of the requirements of the Operational Tool are to be done in MicroStrategy
by the stc team (agreed as part of the previous EBU Credit Scoring Project). However, the
implementation of the Operational Tool is dependent on the outputs of this project, where data
outputted by StrategyOne (originations) and by the Integration Layer (for customer management

20
and collections) that is received by stc (through the event producer) will need to be normalized,
saved, and then made available to MicroStrategy to read and eventually implement the
Operational Tool specifications.

6.3 Stream Deliverables

The deliverables of this stream are:

 Customized integration layer preliminary and detailed analysis document
 Customized integration layer technical requirements document
 Customized integration layer solution implementation
 Event Producer Module
 Others
o Testing documents
o Installation guides
o Log of raised testing issues

6.4 Assumptions

Assumptions:
 No system used by business users (e.g. CRM) will initiate the batch processes. The
initiation will be triggered by an executer web service and execution will not start without
a valid user ID and password – in alternative via a scheduler.
 The execution of batch processes will start its execution once data is ready from stc and
one of below two options can be used:
o Files are uploaded in form of CSV (comma separated “,”)
o Data is loaded on staging DB
 The executor will persist only the data of those columns (variables) into the staging tables
which are required for strategy execution.
 Up to 8 different files (across both batch processes) will be considered for data loading,
and each file will have columns not more than 25.
 Across all processes, the application developed is sized to process as many as 1 million
records in month (based on projection). Revised sizing will be conducted during the
project assessment.
 Derivation of additional variables (new variables create using raw data) will be done by
considering fixed set of fields received.
 Derivation of additional variables is limited to the needs of the EBU Credit Scoring project
outcomes. No additional derivation is in scope.
 The development of a matching algorithm is out of scope. Data will be consolidated using
single matching criteria (the Customer CR number).
 Dedupe check will not be performed in implementation. All such checks are performed on
the stc side prior to sharing the data.
 Extraction of data from stc systems is not the responsibility of the vendor. The vendor will
define the expected data structure and format as part of the workshops.
 stc will provide the data samples for development and testing for all processes in line with
the data structure and format defined by the vendor.
 StrategyOne will send and receive data in the JSON file format.
 The integration layer will store output of the previous two batches (for batch process) and
two months (for online processes) at any given time. Any new data coming in (new
batch / new month) will overwrite the oldest batch / month.

21
  Any analysis, design, or implementation of project outcomes within stc systems is out of
scope (e.g. no design of CRM screens, no implementation of screens, etc.) of this project
and is the responsibility of stc.
 The online / real time integration is not handled as part of the integration layer, and is
instead a direct integration between the CRM and StrategyOne via EAI / ESB
 As all information processed through the Batch and online / real time transactions will be
available in stc, stc systems can query / search the records of existing customers on FDA.

Assumptions related to hardware / software:

 All hardware infrastructure and third-party software (e.g. MS SQL, WebSphere, Windows
OS, Load Balancer, etc.) are procured and installed by stc before the vendor starts the
installation of the package into the stc infrastructure.
 The database will be installed by the stc team. stc shall share the credentials of the
database with the vendor, where the vendor will be responsible for setting up the schema.

Other assumptions:
 stc shall provide a subject matter expert on their IT systems / infrastructure / data to
support in those activities.
 No travel expenses are considered or estimated. Due to the coronavirus situation, all
project activities and deliverables will take place remotely. If travel is required, it will be
billed on actuals.

22
 7 Project Planning

7.1 Project Management Approach

CRIF adopts a proprietary project management methodology developed and refined in 20+ years
delivering credit solutions worldwide. It is based on international quality standards and leverages
experience in delivering customer projects.

CRIF delivery methodology is based on 7 project phases:

 Project Initiation
 Preliminary Analysis
 Detailed Analysis
 Design Phase
 Custom Component Development
 UAT Testing
 Delivery and Go-Live

CRIF has best practices in credit management and is able to perform gap analysis to determine
the most suitable solution
 By comparing as-is with our best practices and offering options for improvement
 By defining and gathering to-be requirement and performing as-is vs. to-be gap analysis

The analysis phase is organized in two steps: preliminary analysis and detailed analysis.

The Preliminary Analysis phase is intended to:

 Explore the context
 Address the project influencing factors
 Align project scope with business needs

The output of the Preliminary Analysis is the High-Level Requirements and consolidated Project
Plan. The Detailed Analysis is intended to:
 Support the refinement and the validation of the target solution
 Deliver the solution in the most effective way

To collect requirements, we usually organize workshops with the customer where we collect the
information to create the first draft of the solution documentation. Project documentation is
written in three versions:
 Initial or draft (prepared by CRIF with input from customer and/or based on our
experience)
 Baseline (reviewed with customer comments)
 Validated, signed off by the customer

This process guarantees a solid base of specifications for the development phase, a reference for
the User Acceptance Tests, and a base for training material, handover and impact analysis of
changes after go live.

23
7.2 Project Mobilization and Initial Assessment

This phase represents the project Start Up as is aimed at:

 Identify project stakeholders
 Define the project organization, methodology and governance (procedures and tools)
 Define communication plan
 Agree on responsibilities
 Set up the technological and infrastructural framework
 Confirm RFP and identify requirements and modules
 Define the priorities between tasks and prioritized list of high-level requirements
 Confirm / review the high-level planning
 Define the release management policies
 Identify major risks and mitigation actions

This phase should last 1 week at minimum in order to assure to achieve its main objective and
not delay the project.

7.3 Project Organization

7.3.1 Guiding Principles

Specific phases of the project will be managed remotely with CRIF resources, with on-site
presence where necessary or applicable.

CRIF has proven to be fully capable of remote delivery, including remote / virtual interactions by
developing solutions and processes that do not require on-site presence.

7.3.2 Team Organization

The CRIF Project Team composition, subjected to changes according to project scope and timing
constraints:
 Project Sponsor
 Account Manager
 Project Manager
 IT Service Manager
 Solution Architect
 Integration Team Lead
 2-3 Business Analyst
 4-5 Product Specialists / IT Developers / QA

Additional experts on specific topics could join the team according to specific needs.

The diagram below shows a standard organization chart for similar projects.

24
7.4 Project Deliverables

Project deliverables have been detailed in for streams 1 and 2 in sections 5.3 and 6.3,
respectively.

Standard project management documents to be delivered are:

 Tentative and final project plan
 Project status reports
 Sign off notices

7.5 Project Plan (Timelines)

A tentative, high level plan is provided below:

Phases and Tasks Month 1 Month 2 Month 3 Month 4 Month 5 Month 6 Month 7 Month 8
Project Kick Off (Milestone 1)
Īnfrastructure Readiness and S1 Installation
Technical & Functional Workshops for ETL & S1
Information Gathering Workshop Completion (Milestone 2)
ETL & S1 Analysis
Documentation
Documentation Sign Off (Milestone 3)
Data Validation
Access Rights (VPN) Readiness for CRIF
Stream 1 - Strategy One (Development & Unit Testing)
Configuration
Internal Testing
Unit & Batch Testing with ETL
Stream 2 - ETL Integration Layer (Development & Unit Testing)
Data Integration
ETL & S1 Testing
Event Producer Development & Testing
Stream 1 & 2 - SIT and UAT
SIT
UAT Execution
UAT Sign Off (Milestone 4)
Go - Live (Milestone 5)

25
It is important to note that the plan:
 Is based on the scope defined and the assumptions made. Any change in the approach
would necessitate a revision in the plan.
 Is highly dependent on the coordination, inputs, and file provision from the STC team.
 The StrategyOne and ETL streams are interdependent and must go hand in hand.
 UAT is limited to 1 calendar month of efforts. If UAT is extended beyond the 1 calendar
month, the Time and Materials Approach (T&M) is considered with a rate of $600 per day.

A detailed plan that includes all project activities will be provided at the start of the project after
completing the startup and requirement analysis phase.

26
 8 Annexures

8.1 StrategyOne Product

8.1.1 Overview

StrategyOne, the CRIF solution for strategic decision management, is a software tool that can
manage and automate the entire decision making processes of an organization covering both its
credit related and non-credit related needs, across the customer lifecycle (engagement,
originations, customer management, collections) in real time or batch mode.

StrategyOne represents a competitive advantage for its users: specifically designed to efficiently
develop, execute, and maintain business decision making processes and strategies in automated
applications for use across different departments, process, products, and segments.

StrategyOne centralizes the definition, storage, and application of the all rules, scoring models,
and decisioning logic used in business operations to provide users with greater automation, more
responsiveness to change, and less expensive distribution and maintenance of their decisioning
processes.

Non-technical business managers and analysts (e.g., users from Risk Management Department,
Credit Department, etc.) can safely and securely maintain their business logic used in IT systems
without being dependent on technical resources, therefore reducing application modification cycle
time, speeding organizational response to changing conditions, and reducing significantly total
cost of ownership for the application overtime.

StrategyOne is designed to allow for the separation of the logic behind business rules, scoring
models, and decisioning logic from the mechanics involved in carrying out the recommended
actions recommended, which are executed in dedicated systems (e.g. StrategyOne would
calculate the collections score and priority, and the collections system would carry out the
collections actions). As such, no changes in the application code of dedicated systems is
required; instead StrategyOne integrates with existing systems in one or more points of each
decisioning process to execute the rules, scoring models, and decisioning logic, and then return
an output to move the process forward.

8.1.2 StrategyOne Modules: Engine and Designer

StrategyOne is made up of two linked software modules:

 Decision Process Designer Module
 Decision Process Engine Module

The Decision Process Designer Module allows the Business User to design, create, manage, test,
and control all the elements of the decisioning process (e.g. rules, scoring models, segmentation,
actions, etc.) in a user friendly way through a graphical user interface. Multiple processes can be
created and managed. The designed process is completely custom to the needs of the
organization. Once the design is completed, the user can deploy the process to the live
environment. In case of any updates to the decisioning process due to changing business needs,

27
the client user can update the process in StrategyOne through the designer module and deploy
the new process to the live environment without any application downtown (a “hot deploy”
mechanism is used where the new process created and deployed becomes effective as soon as it
is deployed).

The Decision Process Engine Module processes is the module that operates in the live
environment, where it received input data for each decisioning process from one of the existing
systems of the organization, processes the input data as per the defined elements (designed
using the Designer Module), and generates the outputs. The output is sent back to the system.

8.1.3 Features and Benefits of Adopting

StrategyOne

The key benefits arising from the adoption of StrategyOne to host the scoring models and
decisioning strategies are:

 Enterprise Decision Making Platform – One single installation of StrategyOne is

capable of managing all the decision processes of the entire organization; covering
different customer lifecycle phases, departments, product, customer segments, etc.
 Multi-Purpose Built – StrategyOne is purpose built for ultimate flexibility where it can
be used for credit and non-credit related decisioning; for engagement, originations,
customer management, and collection uses; for multiple departments, products, and
customer segments; used for real time decisioning on in batch mode.
 Centralized Decision Making – All decision making logic for all business processes
across the organization is hosted, and managed centrally.
 Unmatched Time to Market – Quick configuration, modification, and deployment of
decisioning processes to react to changes within the organization or in the industry and
market.
 Graphical User Interface – StrategyOne comes with a designer module that allow users
to configure decisioning processes without the need of knowing any coding. This module
allows the client to be independent from CRIF for future updates and configuration of
processes.
 Custom Process Design – StrategyOne supports the custom design of decisioning
processes to meet the business needs of the organization, including calculations, rules,
scoring models, decision trees, decision matrices, plug-ins, scripting, decisions, etc.
 Business Team Independence – Once StrategyOne is integrated with other systems of
the organization, business users can take full control of the design, creation, testing,
modification, and deployment of decision processes (using the Designer) without the need
of IT resources.
 Low Cost of Ownership – With the training of users, the organization can be fully
independent in introducing new processes and managing changes thus eliminating the
significant costs of introducing new processes and modifications.
 Debug and Simulation – Inclusion of built in modules to perform unit testing and what-
if analysis on the portfolio to ensure correct configuration and simulate the impact of
changes in the decisioning processes on the portfolio.
 Champion-Challenger – Inclusion of a built in module to run two competing decisioning
processes – the current ‘champion’ process and a proposed ‘challenger’ process – on the
live environment and determine which process performs better.

28
  Process Documentation – Automatically creates full detailed documentation of all
configured processes that are needed for internal record keeping, audit, or regulatory
purposes.
 Process Versioning – Full management of process version with the ability to create
multiple versions, compare versions, generate detailed documentation on each version,
and back-roll to a previous version. All process versions can be backed-up using this
feature within StrategyOne. In addition, all process versions can be exported and
reimported later if needed.
 User Management – Multi user solution with a sophisticated profiling (access rights,
maker, checker) available for the System Administrator to define user profile.
 Audit Logs – Any action executed by users is tracked in the designer Log, where the
Administrator can see who did what and when on which version of the process

8.2 StrategyOne Technical Requirements

29
Note
 Internet connection is required only for designer, not production/runtime engine
 StrategyOne supports both XML and JSON file formats
 StrategyOne supports connection to Rest APIs (using JSON format)

30
31
32
8.3 Integration Layer Technical Requirements

The recommended hardware / software for the production environment are provided below.
Note: these will be revised during the assessment phase. The provided list is indicative.

8.3.1 Software

Items Description/Configuration Remarks

Linux RHEL 5 or Above
Windows Version 2016 / 2019
JDK Version 8 or latest
Standard edition is the reference
version used by CRIF to develop
and test the solution. Enterprise
edition may be explored in the
future in case of performance
optimization required.
SQL Server MS SQL Server 2016

After “test the solution”

Standard edition is applicable in
every environment of the
architecture described in this
document: Dev, UAT, Prod, DR.
Java Java 1.8
Framework Spring Batch, Spring Boot
Decision Engine StrategyOne Engine Part of stream 1
Notepad++ Any version
Microsoft SQL
Server
Management
Studio
WebSphere 9.0 /
Tomcat latest
version
Load Balancer Load Balancer: nginx

8.3.2 Hardware

Items Description/Configuration Remarks

Linux Machine Any Linux machine Backend server
MSQL machine MSQL 2016 Microsoft SQL server

8.3.3 Environments

The list of the environment required are provided below:

 Development environment
 Test environment

33
  Pre-production environment
 Production environment
 Disaster Recovery environment

8.3.4 Sizing and Performance

As part of the assessment activities, the appropriate sizing will be determined on the basis of the
volume and expected level of performance.

Expected volumes based on stc data from the previous few years for each process are detailed
below:
 Process 1: Originations Real Time Process
o Total number of orders:
 2019: 5.04 million orders
 2020: 4.41 million orders
o Average number of orders per month (2018, 2019, 2020): 410K
o Max number of orders per month (2018, 2019, 2020): 723K
o Average number of orders per day (i.e. expected number of daily inquiries): 13.6K
o Max number of orders per day: 24.1K
 Process 2: Behavioral Batch Process
o Average number of customers per month (2019, 2020): 77.4K
o Max number of customers per month (2019, 2020): 80.2K
 Process 3: Collections Batch Process
o Average number of customers per month (2019, 2020): 64.3K
o Max number of customers per month (2019, 2020): 70.5K

34