Pega Smart Investigate Payments 8.3 Implementation Guide

Pega Smart Investigate for
Payments
IMPLEMENTATION GUIDE
8.3
© 2019
Pegasystems Inc., Cambridge, MA
All rights reserved.
Trademarks
For Pegasystems Inc. trademarks and registered trademarks, all rights reserved. All other trademarks or service
marks are property of their respective holders.
For information about the third-party software that is delivered with the product, refer to the third-party license
file on your installation media that is specific to your release.
Notices
This publication describes and/or represents products and services of Pegasystems Inc. It may contain trade
secrets and proprietary information that are protected by various federal, state, and international laws, and
distributed under licenses restricting their use, copying, modification, distribution, or transmittal in any form
without prior written authorization of Pegasystems Inc.
This publication is current as of the date of publication only. Changes to the publication may be made from
time to time at the discretion of Pegasystems Inc. This publication remains the property of Pegasystems Inc.
and must be returned to it upon request. This publication does not imply any commitment to offer or deliver
the products or services described herein.
This publication may include references to Pegasystems Inc. product features that have not been licensed by
you or your company. If you have questions about whether a particular capability is included in your
installation, please consult your Pegasystems Inc. services consultant.
Although Pegasystems Inc. strives for accuracy in its publications, any publication may contain inaccuracies or
typographical errors, as well as technical inaccuracies. Pegasystems Inc. shall not be liable for technical or
editorial errors or omissions contained herein. Pegasystems Inc. may make improvements and/or changes to
the publication at any time without notice.
Any references in this publication to non-Pegasystems websites are provided for convenience only and do not
serve as an endorsement of these websites. The materials at these websites are not part of the material for
Pegasystems products, and use of those websites is at your own risk.
Information concerning non-Pegasystems products was obtained from the suppliers of those products, their
publications, or other publicly available sources. Address questions about non-Pegasystems products to the
suppliers of those products.
This publication may contain examples used in daily business operations that include the names of people,
companies, products, and other third-party publications. Such examples are fictitious and any similarity to the
names or other data used by an actual business enterprise or individual is coincidental.
This information is the property of:
Pegasystems Inc.
One Rogers Street
Cambridge, MA 02142-1209
USA
Phone: (617) 374-9600
Fax: (617) 374-9620
www.pega.com
Pega Smart Investigate for Payments
Document: Implementation Guide
Software Version: 8.2
Updated: November 2019

CONTENTS
Overview ....................................................................................................................... 1-1
Understanding the Basics ........................................................................................... 2-1

Ruleset Overview ....................................................................................................................... 2-1
Organizational Hierarchy............................................................................................................ 2-2
Work Object Model..................................................................................................................... 2-4
Workbasket and Worklist Assignment Models ........................................................................... 2-5
Operators, Access Groups, and Access Roles .......................................................................... 2-6
Security of the Working Environment ......................................................................................... 2-7
Security Components ............................................................................................................ 2-8
Smart Investigate for Payments Security Levels ................................................................... 2-8
Rule Resolution and the User RuleSet List ........................................................................... 2-8
Integrating with External Systems ............................................................................................ 2-11
Deploying the application ........................................................................................... 3-1

Deployment steps ...................................................................................................................... 3-1
The Ruleset Hierarchy ............................................................................................................... 3-1
Creating Your Top-Level Class .................................................................................................. 3-2
Copying MyCoSI-Work to Your Class Hierarchy ................................................................... 3-2
Update the Dynamic Class Referencing ................................................................................. 3-10
Copying the Declare Index .................................................................................................. 3-15
Setting up accounting functions ................................................................................ 4-1

Setting Up Account Types.......................................................................................................... 4-1
Setting Up Internal Accounts...................................................................................................... 4-2
Associating Internal Accounts with Work Pool Classes .............................................................. 4-3
Adding Fields to the Internal Account .................................................................................... 4-3
Setting Up the Chart of Accounts ............................................................................................... 4-4
Setting Up Payment Type Rules ................................................................................................ 4-5
Naming Conventions ............................................................................................................. 4-6
Setting up accounting step rules ................................................................................................ 4-8
Setting Up Accounting Verification Levels ................................................................................ 4-13
Setting Up Accounting Cutoff ................................................................................................... 4-14
Setting Up Accounting Documents .......................................................................................... 4-16
Setting Up Accounting Advices ................................................................................................ 4-18
Setting Up Account Number Validations .................................................................................. 4-18
Setting up your organization ....................................................................................... 5-1

Setting Up Organizations ........................................................................................................... 5-1
Classes Used to Create a Hierarchy and Related Instances...................................................... 5-1
Understanding Security Basics .................................................................................................. 5-2
Authentication and Authorization .......................................................................................... 5-2
Security Configuration Components...................................................................................... 5-3
Creating Smart Investigate for Payments Security Levels .......................................................... 5-3
Configuring Level 1 Security ................................................................................................. 5-4
Defining Evaluation Logic for Rule-Declare-DecisionTree .................................................... 5-8
Defining the Decision Table for SetLevel1Instance .............................................................. 5-9
Setting the Initial Data-Admin-Operator-Security Instances ............................................... 5-10
Creating Access Roles ............................................................................................................. 5-13
Application Privileges ............................................................................................................... 5-14
Controlling Access to Individual Rules Using Privileges ..................................................... 5-14
Associating Access Roles, Privileges, and Classes ................................................................. 5-15
Understanding Access Role Obj Rules .................................................................................... 5-15
Understanding System Production Levels .......................................................................... 5-16
Tabs on the Access Role Obj Form .................................................................................... 5-16
Integrating Smart Investigate ....................................................................................... 6-1

Transaction Data File Interface — PegaRESEARCH Manager ................................................. 6-1
Free-Text Parsing ...................................................................................................................... 6-2
Calling Free-Text Parsing ..................................................................................................... 6-3
The Parsing Process ............................................................................................................. 6-4
Using Regular Expressions................................................................................................. 6-10
Locating New Data Elements .............................................................................................. 6-10
Creating New Work Cases from Messages ........................................................................ 6-10
Searching For Existing Work Cases ................................................................................... 6-11
Interface for Inbound and Outbound Messages ....................................................................... 6-12
Nostro Break Feed Files .......................................................................................................... 6-15
Inbound E-mail Interface .......................................................................................................... 6-16
Outbound E-mail Interface ....................................................................................................... 6-21
Accounting Feed Posting File .................................................................................................. 6-21
Customer Information File Interface ......................................................................................... 6-22
Smart Investigate for Payments Data Tables and Views.................................................... 6-23
Pega 8 Integration Layer .......................................................................................................... 6-24
High level Implementation Approach for Data Page conversion .............................................. 6-26
Retrieve data from Database .............................................................................................. 6-26
Write data to Database ....................................................................................................... 6-26
Data Page Reference Implementation for retrieving the data ............................................ 6-26
Referencing the implementation to write data .................................................................... 6-28
Understanding Reports and Report Scheduling ....................................................... 7-1

MIS Reports ............................................................................................................................... 7-2
Financial Reports .................................................................................................................. 7-3
Message Reconciliation Reports .......................................................................................... 7-4
Compensation Reports.......................................................................................................... 7-4
Using the Schedule Report Function ......................................................................................... 7-5
Adding Reports to the Scheduler .......................................................................................... 7-8
Appendix A: Application-Specific Information......................................................... A-1

System Administrator Account .................................................................................................. A-1
Smart Investigate for Payments RuleSets ................................................................................. A-1
Work Object Naming Conventions ............................................................................................ A-2
Default Work Groups, Workbaskets, and Worklists................................................................... A-2
Remaining in Verification Queue ............................................................................................... A-4
Default Operators and Access Groups ..................................................................................... A-4
Predefined Access Roles and Privileges ................................................................................... A-5
Portal Layouts – ........................................................................................................................ A-7
SI User ................................................................................................................................. A-7
SI Manager........................................................................................................................... A-7
SI System Administrator ...................................................................................................... A-8
Service Level Rules and Escalation Activities ........................................................................... A-8
Correspondence Templates ...................................................................................................... A-9
SWIFT Correspondence Templates ........................................................................................ A-11
Fed Service Correspondence Templates ................................................................................ A-16
Indemnity Correspondence Templates ................................................................................... A-17
Compensation Correspondence Templates ............................................................................ A-17
Standard Correspondence Templates..................................................................................... A-20
Structured Correspondence Templates................................................................................... A-21
Sample Data ........................................................................................................................... A-23
Party Maintenance Data..................................................................................................... A-23
MyCoSI-Party-InternalAccount ............................................................................................... A-24
Appendix B: Sample Modeler Workflows ................................................................ B-1

SWIFT ParseMessage .............................................................................................................. B-4
Fed Service ParseMessage ...................................................................................................... B-5
FreeFormatTextParse .............................................................................................................. B-6
Message Processing StepByStep ............................................................................................. B-7
AcctgRepair .............................................................................................................................. B-8
AcctgRepairDocument.............................................................................................................. B-9
CreateAdjustment ................................................................................................................... B-10
CreateTxnCorrespondence .................................................................................................... B-11
CreateAcctgCorrespondence ................................................................................................. B-12
FinStepVerifOneLevel ............................................................................................................ B-13
FinStepVerifTwoLevels........................................................................................................... B-15
FinStepVerifThreeLevels ........................................................................................................ B-16
SendCorr ................................................................................................................................ B-17
EnterCorrDetailsSF ................................................................................................................ B-18
CorrCreateSBS....................................................................................................................... B-19
SwiftCorrCreate ...................................................................................................................... B-20
FedSvcCorrCreate.................................................................................................................. B-20
AppCorrVerifySend................................................................................................................. B-21
AppCorrTicklerVerifySend ...................................................................................................... B-23
AppCorrRepair........................................................................................................................ B-24
Case Processing StepByStep ................................................................................................. B-25
DuplicateSearch ..................................................................................................................... B-26
Bulk Entry NewWork ............................................................................................................... B-27
BCETranFlow ......................................................................................................................... B-28
BCECollectTRNFromSpreadsheet ......................................................................................... B-29
ProcessInboundIndemnity ...................................................................................................... B-29
ProcessOutboundIndemnity ................................................................................................... B-30
BCNR NewWork ..................................................................................................................... B-32
BCNR...................................................................................................................................... B-33
CoverNonReceipt ............................................................................................................... B-34
UTACr NewWork .................................................................................................................... B-34
UltBeneUTA............................................................................................................................ B-36
UTACover ............................................................................................................................... B-37
UTAStmtCR ............................................................................................................................ B-37
UTEPymtOrder ....................................................................................................................... B-39
Return NewWork ..................................................................................................................... B-40
Corresponding Bank Charges (MT191) New Work ................................................................. B-41
SLAFlow ................................................................................................................................. B-42
VerifySendCorr ....................................................................................................................... B-42
Compensation NewWork ........................................................................................................ B-43
InitialProcessing ..................................................................................................................... B-44
PayBackValue ........................................................................................................................ B-45
PayBackValueSF.................................................................................................................... B-46
ReceiveBackValue ................................................................................................................. B-47
ReceiveBackValueSF ............................................................................................................. B-48
StepByStep ............................................................................................................................. B-50
Appendix C: Text Parsing Rules ............................................................................... C-1

Parsing Dates ........................................................................................................................... C-1
Locate Step .......................................................................................................................... C-1
Manipulate/Translate Step ................................................................................................... C-2
Test/Validate Step ................................................................................................................ C-2
Map/Output Step .................................................................................................................. C-2
Parsing Amounts....................................................................................................................... C-2
Locate Step .......................................................................................................................... C-2
Test/Validate Step ................................................................................................................ C-3
Map/Output Step .................................................................................................................. C-4
Parsing Receiver’s Inquiry References ..................................................................................... C-4
Locate Step .......................................................................................................................... C-4
Validate Step ........................................................................................................................ C-5
Map/Output Step .................................................................................................................. C-5
Parsing Receiver’s Transaction References ............................................................................. C-5
Locate Step .......................................................................................................................... C-5
Validate Step ........................................................................................................................ C-5
Map/Output Step .................................................................................................................. C-5
Parsing Sender’s Transaction References ................................................................................ C-6
Locate .................................................................................................................................. C-6
Validate Step ........................................................................................................................ C-7
Map/Output Step .................................................................................................................. C-7
Parsing IMADs .......................................................................................................................... C-7
Locate Step .......................................................................................................................... C-7
Manipulate/Translate Step ........................................................................................................ C-8
Validate Step ........................................................................................................................ C-8
Map/Output Step .................................................................................................................. C-8
Parsing CHIPS Sequence Numbers ......................................................................................... C-8
Locate Step .......................................................................................................................... C-8
Validate Step ........................................................................................................................ C-8
Map/Output Step .................................................................................................................. C-9
Parsing Work Types .................................................................................................................. C-9
Locate Work Type = Amend Beneficiary............................................................................ C-10
Locate Work Type = Beneficiary Claims Non Receipt ....................................................... C-10
Locate Work Type = Cancellation Request........................................................................ C-11
Locate Work Type = Correspondent Bank Charges................................................................ C-12
Locate Work Type = Duplicate Payment ............................................................................ C-12
Locate Work Type = Incorrect Amount............................................................................... C-13
Locate Work Type = Incorrect Bank Paid .......................................................................... C-13
Locate Work Type = Incorrect Charges ............................................................................. C-14
Locate Work Type = Incorrect Credit Account ................................................................... C-14
Locate Work Type = Incorrect Cover ................................................................................. C-14
Locate Work Type = Incorrect Date ................................................................................... C-14
Locate Work Type = Incorrect Debit Account .................................................................... C-15
Locate Work Type = Return of Funds ................................................................................ C-15
Locate Work Type = Unable to Apply Credit ...................................................................... C-16
Locate Work Type = Unable to Apply Debit ....................................................................... C-17
Locate Work Type = Unable to Effect Payment ................................................................. C-17
Appendix D: Accounting Step Rules and Payment Types ...................................... D-1
Appendix E: Compensation Step Rules and Payment Types ..................................E-1
Appendix F: Glossary .................................................................................................. F-1

Overview
Smart Investigate for Payments is a packaged, scalable solution for managing wholesale
transaction exceptions and automating the inquiry and exception management activities
across numerous departments, including wire transfer, Treasury, nostro reconciliation,
foreign exchange, securities, and more. Smart Investigate for Payments automatically
handles receipt and processing of incoming messages, sending of outbound
correspondence in Fed Service, SWIFT, and other formats, searching for related
transactions, and processing of compensation claims and adjustments.
Smart Investigate for Payments significantly reduces financial risk, lowers operating cost by
dramatically improving investigator productivity, and improves customer service through
faster turnaround. Smart Investigate for Payments is delivered with preconfigured, fully
functional flows for handling your highest volume work types (such as beneficiary claims
and unable to apply), standard inbound/outbound integration with Fed Service and SWIFT
for sending/receiving inquiry messages, and transmittal of actual payment instructions.
Smart Investigate for Payments is designed for immediate use out of the box for
demonstration and training purposes. It comes with a working set of rules and the
supporting infrastructure that can simulate connectivity with your transaction databases.
With a minimal change to existing rules and the implementation of connectivity to your
external systems and databases, you can put the product into production in a short
timeframe. As your experience grows, you can extend the product to standardize,
streamline, and adapt your evolving business processes, using the patented Pegasystems
rule-based architecture.
Smart Investigate for Payments uses a complete set of packaged services to handle the
day-to-day complexity and management of your payment processing exceptions. These
services include the following:
• Case management
− Multibank capabilities
− Straight through processing where applicable
− Efficient UI — single case, bulk case entry, expandable data areas and scrollable
work panels
− Screen icons to display images and attachments (single and multiple)
− Hypertext links to related cases as well as related data found in other cases,
external applications and data objects
− PriorityBulk case processing, including import of spreadsheet
• Message processing
− Free-text parsing of unstructured messages
− Consistent processing of SWIFT, SWIFTNet, Fed Service, e-mail, telex, and other
electronic messages
Pega Smart Investigate for Payments Implementation Guide 1-1

− Ability to automatically attach messages to new or existing investigations
• Paperless environment
− Data captured manually or automatically stored in an electronic folder
− Desktop scanning and archive of supporting source and research documents
• Work routing and assignment
− Automated and manual work distribution
− Option to expose work queues to an operator or “push” work to operators based on
priority, availability, and skill set
− Worklist and workbasket management guided by automatic prioritization
• Service level management
− Goal and deadline time monitoring and escalation
− Online warnings and indicators
− Defined escalation procedures
• Accounting
− Full adjustment accounting module
− Comprehensive audit of time, date and operator for accounting entries
− Multi-level verification
− Accounting document generation in multimedia formats
• Compensation
− Pay, receive, request, claim, and apply interest
− Amend beneficiary
− Use of funds
− Back value
− Forward value
− Indemnities
• Duplicate case searching
− User-defined and managed search criteria and threshold scoring
− Confidence level specification for evaluation
− Auto resolution of duplicate cases
• Correspondence
− HTML- or Microsoft Word-based, user-defined templates for general
correspondence and SWIFT and Fed Service messages
− Automated or manual generation

− Multimedia output channels
− Repair and verification processes
− Include all attachments or most recent attachment by type with outbound e- mail
− Copies to interested parties
• Transaction database integration
− Online search portal for transaction retrieval and review
− Standard access services from within the application
− Customer information
• External system interface and feed capabilities
− Inbound/outbound Fed Service, SWIFT, SWIFTNet
− Customer Information File integration
− Inbound/outbound e-mail
− Inbound Nostro Exceptions File feed
− Accounting transaction feed
− Support for external currency validation
• Reporting
− Standard productivity and throughput reports
− Drill-down capabilities from summary screens to detailed case data review
− Open database for third-party reporting tools
− Standard export function to Microsoft Excel format
− Wizard to facilitate the creation of new reports
− Up to four reports visible on Dashboard
− Report scheduler
• Self Service
− Web Services for most common functions
Pega Smart Investigate for Payments runs in the Pega 8 environment, a business process
management platform that dynamically integrates both process and practice rules.

Understanding the Basics
Before configuring your application, you should understand some of the basic mechanisms
of Pega 8 in relation to your application.
This chapter includes the following topics:
• Ruleset overview
• Organizational hierarchy
• Work object model
• Workbasket and worklist assignment models
• Operators, access groups, and access roles
• Security of the working environment
• Integrating with existing systems
Ruleset Overview
Rulesets store related groups of business rules, serving as containers for various types of
application components. Rulesets also provide security, version control, and functions to
deploy or migrate an application between environments.
You begin customizing your application environment by duplicating existing Pega 8

application rulesets and using them as a starting point to configure your own RuleSets. By
modifying copies of the rulesets instead of the base rulesets themselves (which are
protected), your changes remain isolated from product changes. This isolation allows you
to upgrade the base application and test the changes in your environment before merging
the changes into your rulesets.
The rulesets that come with your application can be divided into these categories:
• Rulesets that define class hierarchies for site-specific work objects and other data,
access roles and privileges for users, home page display, and tools. You must modify
these RuleSets during deployment to suit your environment.
• Rulesets that define product rules and include activities, data model classes and
properties, and the work object hierarchy. You will likely customize these rules, but
doing so is not required for proper product operation.
• Rulesets that are shared across Pega 8 applications, such as PegaApp, which contains
workflow components, PegaAppFin (for financial accounting), and PegaAppResearch
(PegaRESEARCH Manager).
Rulesets are arranged hierarchically, with more general rules at the bottom and more
specific rules at the top. For example, in the following ruleset hierarchy diagram the Pega-
ProcessCommmander, Pega-RULES, etc, rulesets control the underlying Pega 8 operations,
while PegaSINostro, and PegaSI control application functions.

The ruleset order is critical to rule resolution. To find the appropriate rule to execute, Pega
8 begins with the top ruleset in the list and, if the rule is not found, moves to the next
ruleset. In this manner, custom site-specific rules have precedence over application-specific
rules.
Organizational Hierarchy
Pega 8 applications group organizational data hierarchically, using nested levels of
organizations, divisions, and units. This basic organization hierarchy diagram depicts a
sample organizational hierarchy with one organization, three divisions, and four units.

You can use this model as a guide when creating a similar hierarchy to reflect your
organization’s functional and reporting structure:
• Highest Level: Organization — identifies the company entity.

• Second Level: Division — identifies the major entities of the company. For example, you
might use the structure of your company’s senior management team as a starting place
for division-level entities.
• Lowest Level: Unit — identifies the most specific level at which organization information
is recorded (for example, a cost center).
As you are deploying your system, identify the business areas with primary users or
interested work parties. You can add to or modify the structure at any time as your
organization grows and changes. You can display a graphic showing your organization, by
selecting the Administrator bar from the Navigation panel, and then selecting
Organization Chart from the Organization section.
When users log in with an operator ID, the Pega 8 application they log into and their
organizational affiliations grant them appropriate ruleset access. The ID also identifies two
additional affiliations: work groups and access groups.
• Work Groups — users and the work they do are tied to work groups, which fall below
units in an extended organizational hierarchy. Users working on a common set of items
generally belong to a single work group.
• Access groups — users’ application permissions, RuleSet access, portal layout, and
accessible work are controlled by access groups. Access groups may span multiple work
groups, and typically mirror Pega 8 job functions.
The following diagram shows a part of the SampleCo hierarchy. The North America and
Asia divisions each have Marketing and Sales units; each Marketing unit, in turn, has
Marketing Communications and Product Management work groups. All work group
managers are afforded additional privileges by belonging to the Managers access group.

Work Object Model
There are various types of work objects — messages, exceptions, tasks, and so on —
depending on the application and its unit of work.
When your application initiates a work object, a predefined model populates key property
values (such as urgency) that directly affect the work object’s relative priority and
placement in operator worklists. As work objects progress towards resolution, core
property values such as priority and status are continually updated to reflect the current
stage of processing.
There are three types of work objects: basic work objects, covers, and folders. Applications
use basic work objects; some, but not all, may use covers or folders.
• Work objects capture and process information about an individual unit of work.
• Covers tightly coordinate processing of one or more distinct, but closely related, work
objects. The system normally resolves a cover work object after all of its component
work objects are resolved.
• For example, if a customer request creates three separate work objects, the work
objects may follow separate flows, may be handled by separate departments, and may
not affect each other. The cover object provides consolidated visibility to the request,
which can be resolved once each component object is resolved.
• Folders hold one or more work objects (which can be basic work objects, covers, or
other folders). In contrast to covers, the relationship between folders and work objects
and their contents may be many-to-many. One work object may be associated with
multiple folders, but only one cover.

Each work object has a unique ID that is computed by combining a system-assigned
number and a prefix defined by a map value rule. Smart Investigate for Payments uses the
following prefixes:
• The M- prefix is used for message cases.

• The PEG prefix is used for exceptions.
• The CMP prefix is used for compensation cases.
• The CVR prefix is used for bulk-entry payments cases.
See Chapter 5, Setting Up Your Organization, for information about setting up prefixes for
your organization.
Workbasket and Worklist Assignment Models

Your application supports two models for distributing work: worklists and workbaskets.
Both contain prioritized lists of assignments.
An assignment records the condition of an open work object within a flow, and the action
required (by a user or an external system) for the work object to progress. Assignments are
created and prioritized by a flow operating on a work object but are not themselves part of
the work object. Assignments have a many-to-one relationship to work objects, as a work
object may require multiple actions at any point in a flow.
A worklist, automatically created for each operator ID (user), is a prioritized list of

assignments for that user. Worklists are associated with instances of Data-Admin-
Operator-ID, and assignments to worklists are instances of Assign-Worklist.
A workbasket is a shared pool of assignments from which users can select work.
Workbaskets are instances of Data-Admin-Workbasket, and assignments to workbaskets
are instances of Assign-Workbasket.
Assignments can be transferred from a workbasket to a worklist in various ways:
• The system can automatically route assignments to a user’s worklist

• Managers can transfer assignments to a user’s worklist
• Qualified users can move assignments from workbaskets to their own worklists
An application typically has multiple workbaskets to categorize work objects — for
example, a service application may have workbaskets for new tasks, assigned tasks, and
overdue tasks. See Appendix A, Application-Specific Information for a list of workbaskets in
your application.

Worklists and workbaskets function in tandem for more efficient processing and workload
balancing. Routing flows distribute assignments to worklists and workbaskets based on
factors such as individual or group work schedules, workloads, skills, and service level
deadlines.
Additional criteria, such as requiring that users select work from personal worklists before
selecting work from a workbasket, can also be implemented.
Operators, Access Groups, and Access Roles

Pega 8 applications use a combination of operator IDs, applications, access groups, and
access roles to control what each user can see and do within the system. When users log in
with an operator ID, their access group determines their application portal layout and the
RuleSets they can access. Group-specific access roles further constrain the product
functions available to users within that access group.
Smart Investigate for Payments includes an additional security layer that is based on
specific operator-assigned areas of the hierarchy. See Chapter 3, Deploying the Application
for more information.
The following table illustrates some relationships between these factors for a group of
sample users:
• Access Group — System administrators can have unrestricted access to the system, but
system and process architects have more focused roles and can thus operate with the
more restricted access that the SysArch and ProcArch access groups provide. Customer
service representatives (CSRs) might be able to add transactions to the system, but only
Managers can delete transactions.
• Application Portal — Administrators and architects must have access to system rules
and maintenance functions. Managers and CSRs, however, are end users and do not
need to see those elements in their portals.
• Access Role — Users within an access group may not need (or may not be allowed to
have) the same permissions. Manager A and Manager B, for example, are in the
Manager access group and use the ManagerPortal portal, though an access role
distinction could prevent them from reassigning each other’s work objects.

User Type Opera ID Access Group Application Access
Portal
System Administrator sisysadmin@pega.com SISysAdminSample Developer SysAdmin
System Administrator SIPaymentsDev@pega.co SISysAdmin Developer SysAdmin

m
Manager SIManager@pega.com SIManager SIManager SIManager
Supervisor SISupervisor@pega.com SISupervisor SISupervisor SIManager
Manager Diya.cleveland@fsi.com SIManager SIManager SIManager
Supervisor Aline.hunter@fsi.com SISupervisor SISupervisor SIManager
Supervisor Samuel.gill@fsi.com SISupervisor SISupervisor SIManager
Investigator Anand.bullock@fsi.com SIUser SIUser SIInvestigator
Investigator Anna.simmons@fsi.com SIUser SIUser SIInvestigator
Investigator Emi.stephens@fsi.com SIUser SIUser SIInvestigator
Investigator Kelly.goodhue@fsi.com SIUser SIUser SIInvestigator
Investigator Nathan.harrell@fsi.com SIUser SIUser SIInvestigator
Investigator Thane.howard@fsi.com SIUser SIUser SIInvestigator
The above mentioned sample operator records that range from entry-level users to a
system administrator and architect are now shipped as part of Pega Smart Investigate For
Payments Sample layer which is the demo layer and these operator records are not
available in the base Pega Smart Investigate for Payments application These records
demonstrate how access groups define the user’s portal layout and access to rulesets, and
provide models for developing your own user profiles. See Appendix A, Application-Specific
Information, for more information about operators and their access groups.
In addition, standard access roles are available, including the following:
• PegaRULES:SysAdm4 for users with system administrator responsibilities

• PegaRULES:WorkMgr4 for users such as managers or supervisors
• PegaRULES:User4 for users who have might have clerical responsibilities
Note: Do not delete or use these operator records unless instructed to by Pegasystems. Pegasystems
uses these operator records when qualifying issues.
Security of the Working Environment

Your application is preconfigured with usable security models that you can further
customize to support your organization. The following sections describe some of the
mechanisms through which your application and the underlying Pega 8 architecture
provide a secure working environment.

Security Components
The security model includes the following components:
• Operator ID and password — both are required for users to access the system. This is
part of the Pega Smart Investigate For Payments Sample layer.
• Authentication and authorization — using the product requires both authentication and
authorization. Authentication is the validation of users’ identities via operator IDs and
passwords when they log on; authorization is the use of access roles and privileges to
provide access to specific classes and rules.
• Access roles — these provide users access to specific classes and privileges.
• Access groups — these provide groups of users who require the same security settings
access to particular rulesets and portal layouts.
• Workbaskets and routing — workbaskets are shared pools of assignments from which
users select work. Routing activities distribute assignments to user worklists based
upon factors such as priority and operator skill.
• Work pools — users can access the types of work represented in work pools. The work
pools a user can access appear in a selection list on the user’s portal layout. Work pools
are also referred to as class groups.
• Access to business process actions — managers and supervisors control access to
certain business process actions, such as performing manual SLA overrides.
• Access to ActiveX controls — if your security settings allow, ActiveX controls are
downloaded when required. Most controls are for developers, though some may be
required when users perform certain tasks.
Smart Investigate for Payments Security Levels

Smart Investigate for Payments has four security checks to verify that users can access only
the work objects and assignments for which they have privileges. Each of these security
checks is briefly described below. See Chapter 7, “Setting Up Your Organization,” for
instructions on how to set up this security.
• Security Check One — verifies the user has the correct class group for the work they are
performing.
• Security Check Two and Security Check Three — verify the user has the required
permissions to review the object or assignment.
• Security Check Four — verifies the user has the privileges to perform the function on the
assignment.
Rule Resolution and the User RuleSet List

When a user logs in, Pega 8 assembles a unique profile that includes a list of accessible
rulesets, as shown below.
Application instances define access to rulesets and versions. Instances of Requestor,
Organization, and Org Division can optionally specify an application. Therefore, in each
class you can specify an application that defines rulesets and versions available to users of
each class. An application rule in a more specific class overrides an application rule in a
more general class.
The diagram below shows how the system determines which access group among those
specified in an organizational hierarchy to use to form the list of rulesets and versions
available to each user.

The access group BestCo:Guest is specified in the (browser) requestor. That access group is
overridden by the access group BestCo:User for all users who can log in. At the moment,
four users are logged in, and they get the following access groups:
• Jane Dough gets the access group BestCo:Supervisor because it is defined in her
Operator ID instance and overrides BestCo:User.
• Joe Codesmith, who has no access group defined in his Operator ID instance, gets the
access group BestCo:User, which is defined for his division.
• Salil Hill, who has no access group defined in his Operator ID instance, gets the access
group BestCo:Sales, which is defined for his division.
• Sam Chang gets the access group BestCo:Analyst because it is defined in his Operator
ID instance and overrides BestCo:Sales.
When you specify a particular ruleset and version in an access group, the highest ruleset
version that you specify, and all other subversions within that same version, are available to
the user. For example, if you specify BestCo:02-05-03, then users can use the rules in
versions
02- 05-02, 02-04-04, and 02-03-04 of the BestCo ruleset, but no rules in major version 03
are available. If you don’t specify a particular version, all versions are available to the user.

The best practice is to use only major and minor version numbers. This makes revisions
(nn-nn- nn) available automatically without changing user profiles.
Chapter 5, Setting Up Your Organization, describes how to create the proper organizational
components.
The Power and Flexibility of Ruleset Design

After your application is installed, it is immediately usable for demonstration or training
purposes, and with minor changes it is usable for production. In addition, as this table
shows, you can modify the product to suit the needs of your organization.
Personalize Organization name You can add your organization’s logo to the user interface,
User accounts Service levels register users, and establish parameters on policies.
Configure Correspondence templates You can set the product behavior to reflect Data structures
Workbaskets for integration Work management Correspondence
Prioritization templates Accounting your organization’s business
Process activities Party records practices. For example, you can tune work object routing so
that each user receives a reasonable number of objects or
embed your organization’s specific criteria for provisional
credit or write-off decisioning.
Customize New workflows A trained workflow architect can create new business
processes that extend your solution. (Customization
requires the appropriate software license, as well as
expertise with PegaRULES that is beyond the scope of this
document.)
Integrating with External Systems

Many enterprise applications require data sharing — integrating with existing (or legacy)
systems — to realize their full potential and return on investment. Pega 8 implements real-
time interfaces (such as RDB, SOAP, and MQ) to retrieve data and post transactions to
legacy databases, without manipulating the existing data as illustrated below.

Smart Investigate for Payments comes with a sample database that contains typical,
industry- standard data you can use to demonstrate the system out of the box, even at
sites that do not have or have not integrated with pre-existing systems. These sample
tables can also serve as a starting point, or test bed, from which you can develop and test
business logic, modify rules and schemas, and start integrating workflows with external
data sources.

Deploying the application
This chapter first provides an overview of the major steps involved in deploying your
application. It then describes how to set up the ruleset, ruleset version, classes, and basic
user information needed to provide access to the ruleset and classes.
The topics covered in this chapter include:
• Overview of major deployment steps

• The ruleset hierarchy
• Adding your ruleset to the administrator access group
• Creating your top-level class
• Copying the MyCoSI-Work class group to your class hierarchy
• Copying the MyCoSI-EntryFlow Flows to your class hierarchy
• Copying the remaining MyCoSI classes to your class hierarchy
• Copying Data-Admin-DB-Table instances to your class hierarchy
Deployment steps
The following list provides a high-level outline of the general steps involved when deploying
most Pegasystems applications; see Appendix A, Application-Specific Information, for the
specific details regarding your application. This rest of this guide provides more information
about each of these steps.
Create a new ruleset, ruleset version, and top-level class to hold your personalized
business and processing rules.
Smart Investigate for Payments requires additional steps to set up the class hierarchy
for the new customer ruleset.
Create an organizational hierarchy and then add operator IDs, work groups,
workbaskets, and user access groups as needed.
Save product application rules to your ruleset and then make changes as necessary; you
can personalize correspondence, service levels, address types, portal layouts, and so on.
Configure security rules as needed for your organization.
Establish connections to existing external databases and data sources.
If your application requires it, configure supporting applications such as PegaRESEARCH
Manager™, SWIFTNet Exceptions and Investigations, and SWIFTNet Cash Reporting.
The Ruleset Hierarchy

The rulesets provided with your application are locked against change, so you must first
create a ruleset to hold the customization and configuration for your organization. You
then add the personalized ruleset to each access group that has users that need the

ruleset; adding your ruleset to the top of each access group’s ruleset list ensures that the
rule resolution process finds customized rules first.
Creating Your Top-Level Class

Your application uses a hierarchical class structure to define work objects so they can share
common attributes and control rule resolution. A top-level class is a starting place for your
class structure.
For simplicity and clarity, use the same (or similar) names for the ruleset and its top-level
class. In many cases, you may find it useful to define the top-level class as the company
name. For example, SampleCo- could be the top-level class name for the company
SampleCo. For more information on classes and naming conventions, refer to Application
Developer Help or the Community.
Copying MyCoSI-Work to Your Class Hierarchy

Prerequisites:
• Smart Investigate for Payments Sample application is already installed.
Steps to create new application:

To complete the below steps, an operator with below configuration should be created as
this operator is not available in the Pega Smart Investigate for Payments application.
Log in to Pega Smart Investigate for Payments with the above configured operator
Navigate to Application menu and select ‘New Application’ menu item.

Click on ‘Smart Investigate for payments 8’ tile.
Click on ‘Use this application type’ button.

Navigate through screen flow by clicking on ‘continue’.
Navigate through screen flow by clicking on ‘continue’.
Click on Advanced configuration link and update the following fields with the
implementation team data and click on ‘Save’ button.

− Application id
− Organization name
− Division name
− Unit name

Click the Create application button.
Note: Application name Usmart is just an example.
On creation of new application, click on ‘Switch to new application’ button.

Do a save as of SISysAdmin@pega.com operator instance and update the Access Group
selection pointing to newly created application.
Open the application definition of the newly created implementation layer and click on
‘Add application’ link.
Select ‘SmartInvestigateForPayments_Sample’ against Name and ‘8’ against Version.
From the Advanced collapsible menu, uncheck Place properties on thread page only.
Click the Save button.

Copying the MyCoSI-Work class group from the application into your ruleset provides the
necessary data structure for various types of work in your application. Many rules in your
application reference this class data structure.
Class groups are the link between your class structure and the underlying database, and
they must be unique across your organization (the application prevents you from creating
a duplicate name).
To copy the Work Class group:
Click Dev Studio and select the Data Model > Classes and Properties menu item.
Click Clone a Class Group. The first Direct Inheritance Wizard screen appears. Use the
wizard to copy all classes in the class group using your top-level class name as the
prefix.

Complete the fields as follows:
− In the Select a RuleSet Name selection box, select PegaSI_Sample.
− In the Select a Class Group selection box, select MyCoSI-Work.
− In the Map to a new Class Group field, enter ClassName-Work, where ClassName is
the name of your top-level class.
− In the Division field, enter a division if you do not want to use the default.
− Optionally, enter a strategic process name.
Click Next. The second wizard screen (for class mapping) appears.

Change the ruleset name from PegaSI_Sample to your company’s ruleset name so the
rules are created in your ruleset.
Click Next to start replication. The final form identifies the classes, Database Table, and
class group that were created.
For more information on class groups, see online Help or the Pega Community.
Update the Dynamic Class Referencing

Smart Investigate for Payments ships data transform PegaSI-Data-AppExtension.
AppExtension which needs to be saved into the implementation ruleset & class values,
which are created in the implementation layer, to be set in the data transform as applicable
in the implementation layer. Post then Data Page D_AppExtension can be run to check the
results & values picked from the latest implementation classes.

Copying the MyCoSI-EntryFlow Flows to Your Class Hierarchy
You must copy the flow named EntryFlow from each of the MyCoSI-Work-Nostro and
MyCoSI- Work-Pymt classes to your class hierarchy to create the structure required for
Smart Investigate for Payments functions to work.
To copy the EntryFlow rules:
Open the Manage Rules bar, and on the App Explorer tab select MyCoSI Work Nostro-. A
list of classes appears.

For each class, under MyCoSI-Work-Nostro- select Process > Flow > EntryFlow. The
following image shows the EntryFlow instance in MyCoSI-Work-Nostro-Misc.

Click Save As.
Change the Applies to value from MyCoSI-Work-Nostro-Misc to the class group name
created for your ruleset.
Click Save As again to save your changes.
Repeat steps 1 to 5 for each class under MyCoSI-Work-Nostro and under MyCoSI-Work-
Pymt-.
Copying the Remaining MyCoSI Classes to Your Class Hierarchy

You must copy the remaining MyCoSI- classes to your class hierarchy to create the class
structure required for Smart Investigate for Payments functions to work. This includes
functions such as Case Find, the PegaRESEARCH Manager interface, and personalized party
accounts.
To copy the class rules:
Open the Records Explorer, expand SysAdmin, and select Class. A list of instances
appears.
Click the Class Name to sort by class.
Scroll down the list until you see the MyCoSI- classes.

Tip: Use the page numbers at the top of the listing to jump to a particular page.
Click MyCoSI-CaseFind to open the Class form.

Click Save As.
Change the class name to ClassName-CaseFind, where ClassName is your class name.
Select your ruleset from the RuleSet Name selection box. Click Save As to save the
instance in your class. In the Short Description field, replace MyCoSI with ClassName.
Click Save.
Note: For the data rule MyCoSI-Data-, ensure that the Parent class to inherit from (Directed)
field is PegaSI-Data-.
Repeat steps 3 to 7 for every Rule-Obj-Class instance that starts with MyCoSI-, recalling
that the MyCoSI-Work classes were already copied by the Direct Inheritance wizard, and
that there are MyCoSI-WorkAttach- classes that need to be copied in the list following
the MyCoSI-Work classes.
Repeat steps 3 to 7 for the class Index-MyCoSI-WorkParty, copying instances to the class
Index-ClassName-WorkParty.
Copying the Declare Index

You must also copy the declare index rule SICaseFind in the PegaSI-Work- class to the same
name for the class group in your ruleset.
To copy the declare index:

Open the Records Explorer, expand SysAdmin and select Declare Index. A list of
instances appears.
Select the SICaseFind instance in the PegaSI-Work- class. The Declare Index form
appears.
Click Save As.

Change the Applies To value to ClassName-Work-, where ClassName is your class name.
Select your ruleset from the RuleSet Name selection box.
Click Save As to save the instance to your class.
Copying DatabaseTable Instances to Your Class Hierarchy

You must copy the Data-Admin-DB-Table instances for MyCoSI- classes to your class
hierarchy to specify the correct database tables for your new classes. This includes all the
classes that begin with MyCoSI except the instance for MyCoSI-Work (which you created
using the Direct Inheritance wizard), as well as the instances for History-MyCoSI-Work and
Index-MyCoSI- WorkParty.

To copy DB Table instances:
Open the Records Explorer, expand SysAdmin and select Database Table. A list of
instances appears.
Scroll down the list until you see MyCoSI- and open the instance. The Database Table
form appears.
Click Save As.

Change the Class Name field, replacing MyCoSI with ClassName. (You only need to
replace the MyCoSI portion of the name with your class name.) Click Save As to save
the instance in your class.
Change the Short Description field to replace MyCoSI with ClassName when
appropriate.
Click Save.
Repeat steps 3 to 6 for each instance in the MyCoSI- class.
Repeat steps 3 to 6 for each instance in the History-MyCoSI-Work class.
Repeat steps 3 to 6 for each instance in the Index-MyCoSI-WorkParty class.
Note: For the instances of ClassName-RM- classes created, it is expected the Database property will
also need to be updated when PegaRESEARCH Manager integration occurs.
Open the Access Group instance from the operator instance and navigate to Advanced
tab. Update the work pool to <Application name>-Work.
Open the application definition of the newly created implementation layer and delete
‘SmartInvestigateForPayments_Sample’ entry. Click on ‘save’ button.

Setting up accounting functions
This chapter describes the accounting elements installed with Smart Investigate for
Payments that you are most likely to change and personalize during the initial product
deployment.
The topics covered in this chapter include:
• Setting up account types

• Setting up internal accounts
• Setting up the chart of accounts
• Setting up payment type rules
• Setting up accounting step rules
• Setting up accounting verification levels
• Setting up accounting cutoff
• Setting up accounting documents and advices
• Setting up account number validations
Setting Up Account Types

Account types are labels that differentiate and validate the type of account that is
associated with the account number. The account type differentiates the accounts for
display, accounting entries, and reconciliation purposes. Smart Investigate for Payments
processing combines the account type with an account number and bank number to form
a unique key for each account and supports the processing of multiple account types. In
addition, types serve as data points for the sorting and posting of different types of
accounts in the system’s accounting feed file.
Ruleset record affected:
• Rule-HTML-Property named SIPartyAccountType

This image shows the rule for modifying account types.

Setting Up Internal Accounts
Smart Investigate for Payments uses internal accounts in accounting transactions that are
typically not a party in the case. Internal accounts are most often used to define
reconciliation, wash, suspense, and profit and loss accounts. Once defined, internal
accounts form the basis for a lookup table called the Chart of Accounts that defaults
commonly used account numbers and account names into the Smart Investigate for
Payments accounting transactions.
Smart Investigate for Payments ships with a standard set of internal accounts. For
deployment, you create instances of these records in your ruleset and update them with
the appropriate account information. See Appendix A, Application-Specific Information, for a
list of the internal accounts shipped with Smart Investigate for Payments.
Once you create the internal account you must associate it with a work pool class described
in the next section of this chapter.
• PegaSI-Party-InternalAccount instances
This image shows the internal account setup for the Nostro Accounts Payable account.

Associating Internal Accounts with Work Pool Classes
Internal accounts are associated with work pool classes using a map value rule. The map
value rule associates the name used by Smart Investigate for Payments with class names.
To specify the data class you created for the internal account, you must create a map value
rule for your top-level class and ruleset.
• PegaSI-Work FinWorkPoolClasses instances

This image shows the map value rule to associate the internal account with a class name.
Adding Fields to the Internal Account

If you find it necessary to add fields to the Internal Account Setup form, please contact your
Pegasystems Consulting representative for assistance, and follow the steps below:
Create an InternalAccounts class that extends from PegaSI-Party-InternalAccount. This
enables you to add additional properties related to the Internal Accounts and set these
values for each instance of the class. This class can be external or local.
Note: When the PegaSI-Party-InternalAccount class is the parent, your new the class inherits
the properties that are needed for accounting.
Create a Transaction class that extends from the PegaApp-Txn- class specific for
InternalAccount transaction and create the additional transaction level properties to
hold the additional data from the InternalAccounts class.
Modify the transaction class in the Adjustment Step Rules for transactions which default
account information from the Chart of Accounts to reference the new transaction class
you created.
Set the Transaction information:
− If the step rule references an internal account from which to default the values,
confirm the standard chart of accounts map values are set for your class, and
modify the FinChartofAcctsLookup activity to copy the additional properties from
the internal account class to the transaction class.
− If the step rule does not reference an internal account from which to default the
values, modify the following rules to set the values from the new internal accounts
class:
- Modify the Section Rule called FinTxnDetailCreate (to add the new properties)
- Modify Rule-HTML-Property called SITxnDefaultValue and the HTML-Fragment
called FinTxnDtlCreate_Script (to modify the dynamic select and setting of the
properties)
- Modify Posting Procedures (Entry File or SWIFT) to include the additional
properties.
- Modify the Accounting Display (on the work harness) to see the additional
properties
Setting Up the Chart of Accounts

The chart of accounts associates the internal accounts with accounting transactions in
Smart Investigate for Payments. When a debit or credit is defined in an accounting rule to
default from the chart of accounts, the system performs a lookup of this table to get the
account type, account number, bank number, and name of the internal account and maps
it into the debit or credit transaction.
For deployment, save a copy of the chart of accounts to your ruleset and update it with
references to your internal accounts.

• Rule-Obj-MapValue named FinChartOfAccts

This image shows the chart of accounts for Smart Investigate for Payments.
Setting Up Payment Type Rules

Payment type rules define two decision variables related to the processing of debit and
credit entries in the Smart Investigate for Payments accounting steps:
• Whether accounting advices, notifications, or documents are generated with the debit
or credit entry, and in what format (e-mail, mail, and so forth)
• The accounting cutoff time for the transaction, if documents are used for posting
Smart Investigate for Payments comes with a set of predefined payment types. See
Appendix D, Accounting Step Rules and Payment Types, for a list of the Smart Investigate for
Payments payment type rules and the documents associated with those rules. Changes or
additions to payment types also require updates to the accounting step rules described on
page 4-8.
Referenced by:
• Individual debit and credit transactions in accounting steps

Format:
• The Payment Type name can be mixed-case alphabetic characters with no spaces or
special characters.
Ruleset records affected:
• Rule-PegaApp-Financial-PaymentType
Naming Conventions
The name or key to the rules is a concatenated string that describes the debit and credit
accounting roles and the types of accounting messages and documents associated with
those roles. For example:
• The name is DCUS3CWASH202ADV, which indicates debit customer 3 role, credit wash
account, and send a 202 message with SWIFT advice.
• The name is DWASHCCUS3103ADVFED, which indicates debit wash account, credit
customer 3 role, and send an MT103 and Fed advices.
The following images show the tabs to complete to set up the payment type rule.

Field Description
Short Description Required. Short description of the payment type. The default is the instance name.
Details Tab
Name of Cutoff to use Specifies the name of the cutoff rule to use for this payment type. The cutoff rule
identifies the end of the business day.
Stream Name Specifies the name of the stream to be used.
Corr Type Specifies the type of correspondence (document) generated with this payment type,
such as e-mail or a SWIFT message.
Document Required? Identifies if the document being generated is required.
Options Tab
Use Documents for Posting? Identifies if the document generated will be used for posting accounting entries. If
checked, entries will be made to the accounting posting file.
AlternatePayment Types Identifies if an alternate payment type is acceptable.
Field Description
PegaComBankCorr Tab
Financial Documents — PegaCommBank Corr Only

Field Description
Stream Name Specifies the stream to be used to generate the financial document.
Correspondence Language Specifies the language to be used when generating the document.
Correspondence Type Specifies the type of correspondence being generated for this financial document.
Document Required? Identifies if this document being generated is required.
Financial Advices — PegaCommBank Corr Only
Stream Name Specifies the name of the stream for the financial advice.
Correspondence Language Specifies the language to be used when generating the advice.
Correspondence Type Specifies the type of correspondence to generate for this financial advice.
Document Required? Identifies if this document being generated is required.
History Tab Required. Full description of the instance and information on its usage.
Setting up accounting step rules

Smart Investigate for Payments uses accounting rules to define the debit and credit entries
for adjustment transactions supported by the workflows. Called accounting steps, these
adjustment rules define a one-time accounting transaction that creates a balanced set of
debit and credit account entries.
Accounting rules share the same class structure, including the key. The key consists of the
class of the case for which the accounting is being processed, the accounting action, and a
step descriptor or type.
When deploying Smart Investigate for Payments, you need to consider and update a
number of data elements in the accounting step rules. See Appendix D, Accounting Step
Rules and Payment Types, for a list of the accounting step rules and associated payment
types. To modify a step rule, first save it in your ruleset, and then update it. The updates
typically include one or all of the following tasks:
• Add verification to a step

• Update the payment type

• Change account defaulting information to use different party roles
• Reference different internal accounts listed in your Chart of Accounts
• Rule-PegaApp-Financial-Adjustment Naming Conventions

The name or key to the step rules is a concatenated string that describes of the type of
adjustment it generates. For example:
− The name InternalAdjustment1DR2CR generates one debit and two credits.

− The name ReversalDR reverses a debit entry.
− The following shows the Step tab of the Adjustment Rule window for the instance
PegaSI-Work-Adjust-InternalAdjustment1DR2CR
The image below shows the Transactions tab for the same instance; the screen is wide and
you must scroll from left to right to see all the fields. These fields, and their use in creating
new step rules, are described in detail below.
The following shows the PegaCommBankCorr tab for the same instance. These fields and
their uses are described below.

Field Description
Short Description Required. Short description of the step rule. The default is the instance name.
Step Tab
Class of the Step The class of the page that holds the Step data. Specify a Rule-Obj-class name that
is a concrete child class of PegaApp-Step-.
Activity for Verification Flow An activity at the class of the step that calls a verification flow. If blank, the system
automatically bypasses verification. One activity delivered with the product specifies
a verification flow based on amount values. The system also has four verification
flows (no verification required, one level, two levels, or three levels of verification
required), which can be used based on the amount of the step.
Model to create Step A rule of type Rule-Obj-Model at the class of the step. If specified, the system
creates the step page based on the model. The step rules in the product do not
Validate Activity Reserved for future use.
Likelihood An integer between 0 and 100 used to preselect the most likely step rule (the one with
the highest number) during the manual flow actions that create accounting steps. The
flow actions find all step rules that apply to the flow action.
Value Dates Balance
Value Dates Different If checked, you can use different value dates.
Value Dates In Past If checked, you can use value dates in the past to calculate the
accounting transaction.
Transactions Tab
Field Description
Group Specifies if this transaction is part of a group of transactions such that only one
transaction in the group will be used when the accounting is created. In manual
processing, the user selects which transaction from the group to choose (the
Label property is displayed in a selection box so only one transaction can be
chosen). In automatic processing, the first transaction in the group is selected,
so the order is significant.

Field Description
Label This value appears in the window during manual accounting creation flow actions
to indicate to the user what the transaction is.
DR / CR Indicates if the transaction is a Debit or a Credit. The rule requires that debits are
listed before credits for consistency, as the order of the transactions in the rule is
the order in which they are displayed during manual accounting creation flow
Role A unique string identifier for each transaction in this step. Its value is placed into a
property named Role in the transaction of the step, and can be used to find or
report on the transaction.
Txn Class The class of the page that holds the transaction data; specify a Rule-Obj-Class
name that is a concrete child class of PegaApp-Txn-.
Pymt Type Name of Rule-PegaApp-Financial-PaymentType rule to use for this transaction.

The payment type rule associates correspondence with the transaction.
Protect PymtType? If selected, the user interface during manual accounting creation does not allow
input in the Pymt Type field. If not selected, users can modify this value during
manual accounting creation.
Default Account From Where to acquire the account name and number for this transaction:
• Work Party — Take from the Party role in the work object. (The role is
specified in the DefaultAccountValue property.)
• Chart of Accounts — Take from a specified internal account. The value of
the DefaultAccountValue property is used in a lookup to a map value rule
named ChartOfAccts at the class of the work object; this returns a key to a
Data Party record. A second map value rule is used at the class of the work
object to determine the actual party class that this key should be looked up in.
It finds the party class by looking up the value InternalAccount in the map
value rule WorkPoolClasses.
Account From Value Specifies a party role if the Default Account From value is Party. Specifies an internal
account name (as defined in the map value ChartOfAccts) if the Default Account
From value is Chart of Accounts.
Protect Account? If this field is selected, the user interface does not allow input in the Account Name
or Number fields during manual accounting creation. If this field is not selected,
users can modify these values during manual accounting creation.
Default Amount From This specifies where to acquire the default amount value for this transaction:
• Property — Defaults to the amount from the property specified in the
Amount From Value field.
• Literal — Defaults to the literal amount entered in the Amount From Value field.

Field Description
Amount From Value Specifies a property reference if DefaultAmountFrom is Property. A reference can
be any fully qualified property reference from any page, but if the property
reference is not dot qualified, then it assumes the property will be found on the top
level of the work object page.
Specifies an actual amount number value if Default Amount From is Literal. Do not
use quotes, $, or commas (that is, specify 1000.00 and not $1,000,00 or $1000.00
or “1000.00”).
Default Currency The default currency for the transaction.
Protect Amount? If this field is selected, the user interface does not allow input in the Amount field
during manual accounting creation. If this field is not selected, users can modify
this value during manual accounting creation.
Default Value Date From Specifies the value date for the From account.
ValueDate From Value Specifies the value date for the From value.
Protect ValueDate? If this field is selected, the user interface does not allow input in the Value date field
during manual accounting creation. If this field is not selected, users can modify the
value date during manual account creation.
PegaCommBankCorr Tab
Party Role A unique string identifier for each transaction in this step. Its value is placed into a
property named Role in the transaction step and may be used to find or report on
the transaction.
Stream Name Specifies the name of the stream to be used with this transactions.
Correspondence Language Specifies the language to be used for any correspondence (documents) generated
for this transaction.
Correspondence Type Specifies the type of correspondence (documents) to be generated for

this transaction.
Document Required? Specifies if documents are required to complete this transaction.
Security Tab
Name Optional. Enter the name(s) of any named privileges where access to the
privilege allows this step to be executed.
Field Description
Class Optional. Enter the class of privileges you specify in this window.

When Name Optional. Enter a When rule that must evaluate to true to allow this step to be
executed. Most step rules in the Smart Investigate for Payments product use When
rules to allow access to the step only if the Party Role referenced in the step exists in
the work object.
History Tab Required. Full description of the instance and information on its usage.
Setting Up Accounting Verification Levels

Smart Investigate for Payments supports up to three levels of accounting verification. These
levels are based on the base currency value of the step amount (total of debits or credits).
The verification level also represents the number of times a transaction must be verified
before it can be posted to the system’s accounting feed file, when the association
documents are sent.
Accounting steps come with verification enabled.
Privileges assigned to an operator determine the dollar levels that operators have the
authority to verify. Although an operator can have the security to verify at multiple levels,
an operator cannot verify a single transaction more than once.
To include verification in your other business flows, you must set up your verification levels
in the map value rule named FinVerificationFlowByAmount and then update the
accounting rules. In the accounting rules, you specify an activity called FinVerifyByAmount
in the Activity for Verification Flow field on the Step tab of the rule. It is this activity that
calls the mapped value during processing to set the verification level of the transaction.
For deployment, review the verification values and update if necessary to meet your
institution’s requirements.
Referenced by:
• Accounting steps
• Verification flows and workbaskets
Format:
• Threshold amount is a numeric, whole number or two decimals, no commas

• Amount is and up to and including evaluation
• Rule-Obj-MapValue- named FinVerificationFlowByAmount

The following image shows verification levels for FinVerificationFlowByAmount.
Setting Up Accounting Cutoff

Smart Investigate for Payments supports the use of warning and cutoff times for
accounting transactions which enables your organization to run end-of-day accounting
feeds and reports on reconciliation and balances.
When Smart Investigate for Payments is installed, accounting cutoff is not enabled. It is set
up to bypass the evaluation of cutoff times for all accounting entries — enabling round-
the-clock processing of your outgoing debits and credits. This is configured by referencing
a cutoff rule named Default in all of the payment types shipped with the product. This rule
references a special instance of Data-Admin-Calendar called AcctCutoff that has all days of
the year set to business days.
If you want to enable accounting cutoff for your organization, follow the setup instructions
below.
You can use multiple cutoff rules to differentiate different accounting extraction and feed
schedules.
Cutoff can be activated in two modes: Standard and Future.
• Standard — You or Smart Investigate for Payments can continue researching and
processing cases but the standard cutoff prevents accounting transactions from posting
until a specified release time is reached. In most instances, work on the case can
continue until a workflow or transaction point is reached where processing cannot
advance until the transaction is posted. Installed, this is the default cutoff mode.
• Future — You or Smart Investigate for Payments can continue researching and
processing cases and continue posting transactions after the day’s cutoff has been
reached. When processing in this cutoff mode, debit and credit transactions in the step
are posted to the accounting posting file with the next business day’s date and a time
of 00:05:00 so it posts normally on the next business day. This means the accounting
feed must be extracted by date ignoring the time stamp. The online display shows date
and time as entered in the posting file so you know what was done between cutoff and
the next business day. This method also works well for weekend processing.
Note: Transactions held for cutoff are always held as balanced transactions. Debits and credits are
not separated prior to posting.
Referenced by:
• Payment Types used in the accounting step rules

• Accounting displays that identify entries held for cutoff
• Online indicators that identify entries that passed warning or cutoff times
Format:
• Time — set in 24-hour notation format of hhmmss

• Naming scheme — should describe the accounting deadline (for example, DDA or
General Ledger)
• Rule-Obj-MapValue named CutoffType — defines the type of cutoff; defaults to Hold for
Standard mode, and update to Future for Future mode
• Rule-Obj- MapValue named CutoffCalendar — defines which calendar to reference for
work dates
• Rule-PegaApp-Financial-Cutoff — defines the cutoff time, one instance for each cutoff
schedule needed
Note: If you do not use cutoff functions during initial deployment, you do not need to copy the
records.
The following figure shows an example of the cutoff type form.

The following shows an example of the cutoff calendar form used to select the calendar to
use for cutoff.
The following shows an example of the cutoff calendar rule used to define the cutoff times.
Setting Up Accounting Documents

Accounting documents are entered in an accounting step and when generated become
attachments to the case. Accounting documents can be created automatically as part of

adjustment processing or manually when users elect to send an additional document.
Users select the document(s) to send from the Additional Documents selection box.
Smart Investigate for Payments uses correspondence templates to generate accounting

documents. See Chapter 5, “Personalizing Smart Investigate for Payments,” for information
on creating and modifying correspondence templates. See Appendix A, Application-Specific
Information, for a list of the accounting templates.
Accounting can generate correspondence for transactions that are not defaulted from work
parties, if a party role exists. If the following characteristics apply: a non-work party
transaction has a payment type that specifies PegaCommBank correspondence; the
correspondence type is in a decision tree; and a valid party role exists for the case, then
Smart Investigate automatically creates the correspondence and addresses it to the party
role. Otherwise, no document is created.
If you customize correspondence, you can override this decision tree rule for Types or
correspondence that does not derive addresses from the party role.
• PegaApp-Doc- decision tree named InternalAccountDocTypes — lists the valid

correspondence types accounting creates for internal accounts. As shipped,
Swift_MT103 and Swift_MT202 as the only valid types (Figure 5 17).
Referenced by:
• PegaCommBank-Work- activity named CheckInternalAccount — This activity verifies that

the type is valid and that the Inquirer role exists before generating the correspondence.
If the Inquirer role is not required, you can override this activity to check for and use a
different party role, as the correspondence modules require a valid party role.

Setting Up Accounting Advices
In addition to financial documents, you can include a correspondence advice to a work
party as part of an accounting step. This would be useful when reversing a debit and credit
while simultaneously notifying the inquirer of your actions.
Advices are added using the Add a Document flow action at the end of an accounting step.
For an advice template to appear in the list of available templates at run time, the template
must follow a naming convention and begin with the characters ADV.
Setting Up Account Number Validations

Account numbers can be numeric, alphanumeric, or can include special characters. Account
number validation helps to eliminate errors when users enter account numbers in
accounting transactions. For example, you might want account numbers for transactions
to only contain valid SWIFT characters. You can use a property (TxnAcct) in the PegaApp-
Txn- class to set up account number validation.
Copy this record into your ruleset. In the Validate field, either select an instance using
SmartPrompt or create a new instance. For example, to validate SWIFT characters, select
ValidSWIFTCharSet.
• PegaApp-Txn- property named TxnAcct

The following shows the rule for setting up field validations.

Setting up your organization
This chapter describes the tasks involved with setting up your organizational hierarchy,
structure, and security.
The chapter includes the following topics:
• Setting up organizations, organization divisions, and organization units

• Understanding security basics
• Creating Smart Investigate for Payments security levels
• Creating operator IDs, access groups, and access roles
• Application privileges
• Associating access roles, privileges, and classes
• Creating portal layouts
• Downloading and installing ActiveX controls
Setting Up Organizations
Pega 8 applications use a three-level organizational hierarchy that you can create and
modify as necessary. The hierarchy defines the business reporting structure in nested
levels of organization, division, and organization unit.
In addition to the three organization levels, Pega 8 uses work groups to define a group of
workers with a common work manager. A work group does not have to follow the
organizational hierarchy, however; work groups can include people from various
departments in the organization. The importance of work groups to your application is that
they are used by flows to route and escalate work. A user who has a worklist to which you
want to route work must belong to at least one work group.
Most applications come with a sample organizational hierarchy, described in Appendix A,

Application-Specific Information. The application supports extension and growth of the
organizational structure as the need arises. As you think about how to define your
organization, you may want to look at the business structure of your company and your
company’s organization chart.
The organizational hierarchy that comes with Smart Investigate can be extended. Each
division in the organization hierarchy also has workbaskets that have been defined. The
following shows the organization hierarchy. To leverage this organization hierarchy, copy it
to your ruleset.
Classes Used to Create a Hierarchy and Related Instances

During application deployment, you create instances of the following classes:

• Data-Admin-Organization — defines the top level of the hierarchy
• Data-Admin-OrgDivision — defines the middle level of the hierarchy
• Data-Admin-OrgUnit — defines the bottom level of the hierarchy
An organization is the top level of the three-level organizational hierarchy available to all
your applications. The middle level instances are known as divisions. (Data-Admin-
OrgDivision class). The lowest level is the organization unit level (Data-Admin-OrgUnit class).
One PRPC system can support multiple organizations. By convention, organization names
are in LDAP format — such as pega.com — also called the network domain format. The
organizational structure affects Management reporting and statistics visible in the Monitor
Activity workspace.
Below organizations, divisions are the middle level of the organizational hierarchy and are
designed to correspond to cost centers. Most applications create one or more default
division names, see Appendix A, Application-Specific Information. Do not delete these
names.
Below divisions, organization units are the next level of the hierarchy, though they are not
used in security. The installation process creates one or more organization units. See
Appendix A, Application-Specific Information. Do not delete these units. Create one form for
each unit. You can create an organizational hierarchy in which organization units report to
other organization units, which lets the system model large organizations. This hierarchy
does not affect execution.
Understanding Security Basics

This section describes the basic Pega 8 security mechanisms. It explains how you can
modify the security rules or add your own if necessary.
This chapter cannot explain the full scope, depth, and flexibility available with Pega 8
security. For more information, see the Administration and Security section on the
Community.
Authentication and Authorization

Pega 8 provides security capabilities that are both flexible and layered. The security model
is based on user authentication for system access and on authorization for particular
application elements once users are logged in.
Authorization features allow you to define access at different levels:
• Your ruleset and versions

• Classes (types of work)

• Certain individual rules, such as flows
Standard security rules provide access to rulesets, classes, and individual rules, many of
which may suit your access requirements with little or no modification.
Security Configuration Components

When setting up security, you configure the following components:
• Operator IDs — include information that identifies the user. The ID includes the
operator ID name, a log-in password, and the access group to which the operator
belongs.
• Access groups — identify users with the same security requirements. Each user must
belong to at least one access group, which is referenced in the user’s operator ID.
• Access roles — define roles as having certain class access rights. A user can have one or
more access roles, which are referenced in access groups. All users in the same access
group have the same roles.
• Privileges — defined to allow a user with a particular role to access certain functions in
the application. Privileges are associated with access roles and classes, not individual
users. Users have the privileges associated with their access role.
• Access role obj rules — specify relationships between access roles, the classes a role
can access (including at what level and/or under what conditions the access is
permitted), and the privileges associated with that class and access role.
The following sections describe how you can modify the standard security components or
add your own if necessary.
Tip: You must specify roles when creating access groups. Therefore, you should plan and name the
access groups you need before creating roles.
Creating Smart Investigate for Payments Security Levels

Within an organization, business requirements may dictate that users be restricted from
viewing or working on assignments. Smart Investigate for Payments has four security
levels that you can use to define what work objects or assignments users can access.
The criteria for deciding the level of access restriction are a user’s assigned role,
operational unit (for example, branch), and business area (for example, Payments) related
to the investigation case. Client requirements may use one or more criteria, with the
significance and order of each carrying varying weights.
Smart Investigate for Payments provides a fully customizable set of rules that allow
organizations to restrict or prohibit access based on multiple layers of security. Three of

the rules must be assigned to an individual user, and a fourth is based on the user’s access
group.
The security levels assigned to users are defined in their Data-Admin-Operator-Security

profiles. This table illustrates typical business segmentation for security levels.
Level Definition Example

1 Financial institution Bank name (one or many for a multi-bank scenario)
2 Division of financial Either branch or business area

institution
3 Further division of level 2 Either branch or business area
4 Further division of level 3 A team within a branch or business area
Worklist or Workbasket Lowest division of work An individual operator or workbasket within a team
Note: Level 1 is the highest security and is usually a single value given to the bank running the
application. However, if Smart Investigate for Payments is being deployed in a multi-bank
environment, level 1 may contain more than one value.
An initial task in the deployment of Smart Investigate for Payments is the definition of a
business model. The business model defines how the levels will be used and what values
each level will contain. These levels are then defined in the system prior to being assigned
to a user.
The following steps are required to deploy the Smart Investigate for Payments security
solution:
Configure security levels 1, 2, and 3

Define evaluation logic for the decision tree rule SetSecurityAccessMode (of type Rule-
Declare-DecisionTree)
Define the decision table rule SetLevel1Instance (of type Rule-Declare-DecisionTable)
Set initial Security instances (of type Data-Admin-Operator-Security):
a. Verify that Data-Admin-Operator-Security instances reference the activity
SIOperatorLogon
b. Update class-based Rule-Obj-Validate (that is, MyCoSI)
Configuring Level 1 Security

Set the level 1 security for your organization. Each time an operator changes the work pool
class in focus, (representing a switch between entities in a multi-bank scenario), the list of
assigned values for this operator is re-evaluated —see the clipboard properties
pxRequestor.OperatorSecurity.AssignBranches and AssignLOB. Because the Primary
Search List remains on a session-permanent page, it can be used by associated
applications such as PegaRESEARCH Manager.
Smart Investigate for Payments comes with one sample value for Level 1, named MyBank.
To set up Level 1 security:
Navigate to Data-Operator-Security-Level1. The MyBank instance appears.

Click Create. Enter a key to identify your level 1 instance. Click Create and Open. The
Operator Security form for level 1 appears.
Complete the fields as described in the following table.

Field Description
Description Short description, displayed in reports. The default is the instance
name.
Level 2 Validation The name of a property in a work object that is referenced in the
SISecurityCheck2 WHEN block.
Level 3 Validation The name of a property in a work object that is referenced in the
SISecurityCheck3 WHEN block.

Field Description
Primary Search List A property in the Operator Security profile that contains the list of values
referenced when evaluating security by associated applications such as
PegaRESEARCH Manager. This property can point to either the assigned
Level 2 values (property
.AssignedL2) or the assigned Level 3 values (property
.AssignedL3).
Line of Business List A property in the Operator Security profile that lists all Lines of Business for
this Level 1 instance.
Click Save. Repeat the process for each level 1 value you want to add.

This table shows the sample values provided with level 2 security. Set level 2 security so it is
applicable for your organization.
Key Value Description

BRU Brussels
COP Copenhagen
FFT Frankfurt
HEL Helsinki
HKG Hong Kong
LON London
NYC New York City
OSL Oslo
PAR Paris
SIN Singapore
STK Stockholm
Key Value Description

SYD Sydney
TYO Tokyo
ZUR Zurich

Navigate to Data-Operator-Security-Level2.
Enter information in the Description and Associated Level 1 fields as described below.
The following shows a form with sample data.
− Description: Text that appears during work processing in the users’ selection boxes.
− Associated Level 1: A property SmartPrompt, populated with information from Data-
Operator-Security-Level1.
Click Save.
Repeat the process for each level 2 value you want to add.

This table shows the sample values provided with level 3 security. Set the Level 3 security
for your organization.
Key Description
MsgCase MsgCase
Nostro Nostro
Payments Payments
Navigate to Data-Operator-Security-Level3. A list of instances appears.


Enter information in the Description and Associated Level 1 fields as described below.
The following image shows a form with sample data.
− Description: Text that appears during work processing in the users’ selection boxes.
− Associated Level 1: A property SmartPrompt, populated with information from Data-
Operator-Security-Level1.
Click Save.
Repeat the process for each level 3 value you want to add.
Defining Evaluation Logic for Rule-Declare-DecisionTree

During the log-in process, the activity OpenOpSecurInstance (Data-Admin-Operator-
Security) evaluates the decision tree rule setSecurityAccessMode to determine which
access mode option (Individual, Group, Unit, Division, or Organization) is applicable for the
user.
The decision tree rule returns a value to the property

pxRequestor.OperatorSecurity.AccessMode which opens a security profile related to the
result.
Individual — IND
Each Data-Admin-Operator-Security instance is created under the same key as a Data-
Admin- Operator-ID instance. You can use the clipboard to see that the instance has
opened.
The default setting for setSecurityAccessMode is IND (Individual).
The rule can be customized in a local ruleset to meet requirements with additional levels of
Unit (UNT), Division (DIV), and Organization (ORG).

WorkGroup — GRP
Each Data-Admin-Operator-Security instance is created under the same key as a Data-
Admin- WorkGroup instance. All members of the access group derive assigned values from
a single security instance.
For example, both work groups could be set to return a value of GRP, in which case Smart
Investigate for Payments opens a database record keyed on WorkGroup1 for OperA. This
could maintain a different set of assigned values from that of OperB and WorkGroup2.
• OperA WorkGroup1
• OperB WorkGroup2
To change the security access mode:
Navigate to Data-Admin-Operator-Security and select the context Decision from the

pop-up menu of class types. Make sure Decision Tree is checked in the right column. A
list of decision trees appears.
Select setSecurityAccessMode to display the decision tree form.
Click Save As, select your ruleset and version, and click Save As again.
Make the changes you want and when done click Save.
Defining the Decision Table for SetLevel1Instance

The decision table rule SetLevel1Instance is referenced by the security module for
determining the name of the current work pool selected and is matched with its level 1 key
value.
To define the decision table:
Navigate to Data-Operator-Security-Level1 -> Decision -> Decision Table.

Select SetLevel1Instance to display the decision table form.

Click Save As, select your ruleset and version, and click Save As again.
Update the decision table to reflect the work pool that you created (an instance of Data-
Admin-DB-ClassGroup). In a multi-bank scenario this table will contain multiple rows.
Click Save.
Setting the Initial Data-Admin-Operator-Security Instances

Before you create the initial security instance, you should understand the following:
• Creating new instances of Data-Admin-Operator-ID should be limited to operators with

the SISecurityAdmin access group. Add operators using the Add Operator link in the
Organization section of the Administer tab.
• Users with the SISupervisor, SIManager, or SISecurityAdmin access groups can maintain
operator IDs. This is done using the Manage Operator Schedules and Profiles link in the
My Group section of the Process Work tab.
• Each operator/group is required to have access to a supplementary data record that
includes assigned level 2 and level 3 access appropriate to that operator or group. This
information is used extensively when Smart Investigate for Payments evaluates the
appropriate level of access to a work object and processing functionality.
• Access can be maintained at a combination of group and individual level as required.
• Not having a Security record does not prevent users from logging on. It simply means
that access to do any meaningful updates is severely limited. Standard Pega 8
functionality prevents users from logging on until an operator ID is created.
Assigning Values to an Operator

Each separate security instance is assigned to the operator as appropriate. If a new
instance is configured, then no automatic access rights are assigned to or “assumed” by
the users. For the new instance to become available to users it must be assigned.
However, a special override facility can be configured to effectively assign all options. Then,
if individual instances are created or deleted, no additional maintenance needs to be done.
This override profile provides a high degree of access rights, so it should be carefully
reviewed before implementation.
A checkbox is available for disabling a user profile. When checked, the user is temporarily
suspended from accessing work objects because the Security Check 2 or 3 When rule
returns the value false regardless of assigned values. This feature combines a powerful
control with an easily accessed on/off switch.
To add a new Data-Admin-Operator-Security Instance:
Navigate to Data-Admin-Operator-Security. A list of instances appears.

Click New. Enter the User Identifier and click Create to display the Operator Security
form. The user identifier must match an existing instance of Data-Admin-Operator-ID.
This example shows a form with sample data.
Complete the Details tab as appropriate:

− Operator Name: Required field; enables easy recognition when the operator ID keys
are not in a user-friendly format.
− Phone: Optional field.
Click the Assigned Values tab and complete the fields as appropriate as shown in the
example below.
− Use the SmartPrompt to select values from the full Levelx sets.
− Repeat sections enable multiple instances of associated values to be assigned.
Activities embedded with the dynamic select controls ensure that only valid
combinations as defined in your business model can be selected.

Click the Override tab and complete the fields as appropriate as shown in the example
below.
− Deny access to ALL assigned values: This is a quick way of temporarily disabling the
operators access. If checked, all values in the Assigned tab will be ignored.
− Use the SmartPrompt to select values from the full Levelx sets.
− By assigning a level 1 instance the administrator is effectively giving access to all
instances regardless of the instances assigned on the previous tab.

After all fields have been entered, click Save.
Verify that All Security Instances Reference SIOperatorLogon Activity

During the Smart Investigate for Payments log-in process, details from the operator’s Data-
Admin-Operator-Security instances are copied to the clipboard. The security function then
references the clipboard to access the data.
The activity to enable this is Data-Portal.SIOperatorLogon and must be referenced in the

operator’s Data-Admin-Operator-ID instance on the Security tab.
Updating Class-Based Validate Rules

During manual case creation, the work object created must contain the appropriate level 2
and level 3 security values for your organization. To ensure all new cases have the
appropriate values, it may be necessary for you to create a decision tree that verifies that
the correct level 2 and level 3 values have been added to the work object. In addition, you
might want to add a validate rule to check that the appropriate field is added when users
click Submit.
Creating Access Roles

An access role is defined as having certain class access rights. A user can have one or more
access roles, which are listed in access groups. All users in the same access group have the
same roles.
Your application includes one or more predefined access groups, see Appendix A,
Application- Specific Information. These access roles typically exist for users who work with

the application: system administrators, architects, managers, supervisors, and basic
operators, for example.
Your application includes one or more predefined access roles, see Appendix A, Application-
Specific Information. Be sure the appropriate access roles are listed in the access groups for
your application users.
Note: Access roles must be associated with the classes to which they provide access in rules of type
Rule- Access-Role-Obj. This association already exists for the predefined access roles included with
your application. If you create a new role, you must associate it with the necessary classes as
explained in the section Associating Access Roles, Privileges, and Classes in this chapter.
When you create an access role, you must specify the access that role has to classes in your
application and any privileges or access settings associated with the relevant class and role
name combinations.
Specifying New Access Roles in Access Groups

A particular role cannot access a class unless that access is explicitly granted in an access
role obj rule. Therefore, you must be sure that any new role you create has the appropriate
access to all necessary classes or that it is combined with other roles in an access group
that together provide the class access needed by the group
A role can inherit access to a class from a parent class, so you do not necessarily have to
create an access role obj rule for every class in your application. For more information on
class inheritance, see online Help or the Community.
Application Privileges
A privilege allows a user with a role to execute certain application functions. Privileges are
associated with access roles, not directly to users.
If a user has the access role with which the privilege is associated, the user has the
privilege. Privileges also play a role in routing work, as users can only receive work items
for which they have privileges.
Your application includes a set of predefined privileges, see Appendix A, Application-Specific

Information.
Controlling Access to Individual Rules Using Privileges

Certain rules, such as activities, flows, flow actions, and correspondence, let you specify
privileges (usually on the Security tab) that a user must have to access those rules. See the
online Help for details on how to add privileges to these rules.

Associating Access Roles, Privileges, and Classes
Access role obj rules (rules of type Rule-Access-Role-Obj) associate access roles with the
classes to which they provide access and with any relevant privileges or access settings.
When
you create a new access role, you must associate it with the appropriate classes using the
procedure in this section or using the Role Editor.
When you associate an access role or privilege with a class, you not only associate the
names of the rules but you also specify the level of access a role or privilege has to a class
or the conditions under which the role or privilege can access the class. This process allows
for an extremely flexible and powerful way of defining class-based security.
Understanding Access Role Obj Rules

You must create or modify an access role obj rule when:
• You have created new classes in your application and need to specify role access for
them. Generally, if you are copying a class from the application ruleset to your ruleset
rather than creating a new class, the access provided with the application classes will
be inherited by your copied classes.
• You have created a new role and need to specify class access for it.
• You have created a new privilege and need to associate it with a particular class and
role combination.
• You have created an access setting rule (of type Rule-Access-Setting) and want to add it
to a given class and role combination.
Before creating an access role obj rule, you should understand how production levels relate
to access control and privileges. These are described in the following sections. For
complete information on access role obj rules, see the Pega 8 — Administration and
Security section of the Community and the online Help.
The following shows an example of an access role obj rule for the class @PegaSI-Work- and
the role PegaSI:User2. Each access role obj rule represents a class/role combination. The
class and role make up the rule’s name. For example, PegaSI:User2@PegaSI-Work- is the
rule name.

Understanding System Production Levels
System production levels are defined by numbers from 1 (least secure) to 5 (most
secure). A system production level number is assigned when your system is
installed. To see your system production level, check Data-Admin-System.
When you enter one of these numbers beside an access control or privilege, you are
specifying the highest production level on which the role can perform the operation.
For example, if users can perform an operation on a production system (level 5),
then they can also perform that operation on all systems having lower security
(levels 1 through 4) such as development or test systems.
This approach allows you to implement one class access model that provides more
restrictive access for a given user in a production environment and less restrictive
access in a less secure environment.
Tip: If you have only one system or don’t want to use this feature, define your access role obj
rules with level 5 access to allow access at all production levels.
Tabs on the Access Role Obj Form

The Security tab shows a list of access controls, for example, Open Instances and Modify
Instances, some of which have numbers beside them. This list represents the types of
access
that the role might have to objects in this class. The number represents the system
production level at or below which the role has this access.
If you enter a zero or leave a field blank, this role on this class cannot access the control.

The Privileges tab shows a list of privileges (actions that can be performed) that this role
has for this class. This list also has a column where you can enter the production level
number at or below which the role can carry out these privileges.
You can also specify a condition on either the Security or Privileges tab under which a role
has access to the control by entering the name of a When rule instead of a number in the
access control field. For example, a when rule called AssignedToMe might check to see if
the current work object is assigned to the user. If that condition is true, a user with that
role can perform the operation identified by the access control.
Some applications make use of the Settings tab, which allows you to enter the names of
access setting rules with a value for each that applies to the class/role combination. See
Administration and Security on the PDN for details on access setting rules.

Integrating Smart Investigate
Smart Investigate for Payments integrates with your information systems and other
Pegasystems applications to improve quality, productivity, and efficiency. Integration is
accomplished using application activities and flows, as well as Pega 8 services and
connectors that support interactions between Smart Investigate for Payments and
external systems, databases, and websites.
The topics in this chapter include:
• Transaction data file Interface — PegaRESEARCH Manager™

• Free-text parsing
• SWIFT interface for inbound and outbound messages
• Fed Service interface for inbound and outbound messages
• Nostro break feed files
• Inbound and outbound e-mail interfaces
• Accounting feed posting file
• Customer information file interface
• Generating a data dictionary (list of properties)
• Smart Investigate for Payments Data Tables and Views
• Pega 8 Integration Layer
For detailed information about integrating your Smart Investigate for Payments system
with o t h e r systems, see PegaRULES Process Commander — Integrating with External
Systems. For additional integration information for Frameworks products, see the
appropriate Framework Implementation Guide.
Transaction Data File Interface — PegaRESEARCH Manager

PegaRESEARCH Manager is a companion product that supports data retrieval for financial
applications. In the course of processing exceptions, service requests, or claims, it is often
necessary to locate historical transaction information to address a current question or
issue and to determine appropriate action. This type of activity is referred to as research.
In the financial services industry, typical examples of stored transactions include the
following:
• Payment transactions such as those made via EBA, Target, CHIPS, Fedwire, or CHAPS
• Payment instructions such as SWIFT or telex messages
• Securities information
The design of a research-oriented database is influenced by financial transaction flows that
are characterized by low query rates compared to volume of data, few updates after initial
load, and predictable rather than ad-hoc querying. PegaRESEARCH Manager databases are
designed with these criteria in mind and offer further value by including tools that manage
the data loading and querying based on Pega 8 strengths.
Free-Text Parsing
Free-text parsing is a facility that can be used to examine and extract information from
blocks of text. Parsing is invoked from activities that can be run from within other activities
or flows. See Appendix C, Text Parsing Rules, for detailed information about the rules used
for text parsing.
Two mechanisms are available to invoke text parsing:
• Text-Normalize — The Normalize function allows users to substitute one text string for a
number of others to standardize formats (such as dates or currency) or text patterns
(such as reference numbers).
• Text-Infer — The Infer method processes a collection of transform rules against the
subject block of text and stops as soon as a specified pattern is detected. The
transform rules detect text patterns using regular expressions, and return the results
or a transformed result, based upon the transform rule.
Smart Investigate for Payments uses flows as control records to manage text parsing. Each
flow links together the values to be parsed, with each value being located by a separate
activity. (The only exception is processes that locate work types, where each work type —
Unable to Apply, Beneficiary Claims Non-Receipt, and so forth — should be its own activity.)
Whether the next activity is called depends on the success of its predecessor.
The following diagram shows an example of a free-text parsing flow and its component
activities.

Calling Free-Text Parsing
Free-text parsing is called only from the NewWork flow of message cases. It is not available
from a manual flow action, or anywhere in exception work case processing. The NewWork
flow calls the FreeFormatTextParse flow immediately after the ParseMessage flow. Smart
Investigate for Payments parses the inbound message (stripping away the header, parsing
Fed Service or SWIFT fields, and so forth) and then calls free-text parsing.
The message class determines which properties are parsed — only block 4 is parsed for
SWIFT messages, otherwise the entire body of the message is sent for parsing.
This table provides examples of field parsing values for Smart Investigate for Payments.

Data Type/Value Parsed how
Sender Value typically occupies a fixed position in the record header.
Receiver Value typically occupies a fixed position in the record header.
Message Date Value typically occupies a fixed position in the record header.
Message Time Value typically occupies a fixed position in the record header.
Message Priority Value typically occupies a fixed position in the record header.
Message Type Value typically occupies a fixed position in the record header.
Sender’s Inquiry Reference Unknown string; often follows a known tag (for example, :20:).
Receiver’s Inquiry Reference Smart Investigate for Payments ID with a PEG prefix, such as
PEG051228-000001.
Sender’s Transaction Reference Unknown string; often in field 21 or following an “Our Ref:” string.
Receiver’s Transaction Reference String, often in field 21 matching a known pattern.
Transaction Date Date pattern in sentence including DD, Dated, and so forth.
Value Date Date pattern in sentence including VAL, Value, and so forth.
Transaction Amount Amount pattern that consists of up to 16 alphanumeric characters

with punctuation preceded by three alphabetic characters.
Transaction Currency Pattern of three alphabetic characters adjacent to a group of

numeric characters.
Work Type Words or phrases that drive a reason for inquiry.
The Parsing Process

There are four main parts to the parsing process:
• Normalizing data
• Parsing data
• Transform Collection
• Transform
Normalizing Data
Before parsing data, the activity FreeFormatTextParseNormalize normalizes it to
standardize values and terms throughout the text. Normalized data to be parsed is stored
in the property. ParsedData.NormalizedText, and the original data is stored in the property
ParsedData.OriginalText. Both forms of data can be viewed in the Message Details section.
Note: If you modify the normalization logic, it may be necessary to modify this activity (in your own
RuleSet) in addition to the parsing rules.
The following shows a simple normalize rule, which identifies expressions such as payment
and amount as transaction amounts.
Parsing Data
Text parsing is done by the FreeFormatTextParse activity, which first calls the normalization
logic and then calls the parsing logic for the following properties:
• Transaction Reference Number

• Work ID
• Incoming TRN
• Transaction Date
• Value Date
• Amount and Currency
• Work Type
Each activity attempts to extract some type of data from the text and may return either a
value or a blank. The following figure shows the FormatTextParseTranDate activity, which
retrieves a transaction date from text.
The following figure shows an infer rule to get a transaction date.
This table describes the fields.
Field Description
Short Description Required. Short description of the rule. The default is the instance
name.

Infer Tab
Look for Required. A pattern or string followed by the name of a Transform

Collection record or a specific string.
Specify “Near” Qualifier Optional. Narrow the search by selecting how and where you want
Near Select “the string” or “a pattern from” and a string or pattern.
Include the characters before Enter the number of characters before the string or pattern to begin the
search in.
Include the characters after Enter the number of characters after the string or pattern to end the
search in.
Place parse Information Into a Page Optional. Identify where you want the search results to be placed.
Named:
Validate Using When: Optional. Evaluate the results returned from the locate search step
against a When condition. The following “Set Value” step only occurs if the
When condition evaluates to True.
Place Extracted Value In: Required. Specify the property into which the output value should be
mapped.
Also Set the Following Optional. Set other properties values (for example, a status).
Pages & Classes Tab
Page Name Optional. Identify each page referenced in a step of this activity.
For activity parameters of type Page, enter the parameter name
here (with no PARAM prefix or period) and the class of the page in
the Page Class field.
Page Class Optional. Select the class of that page.
Mode Leave blank unless this page is accessed indirectly.

Select Prompt if the name in the Page Name column is an indirect page
name (starting with the prompt prefix) and the system is to verify at run time
that the associated page indicated in an activity Call or Branch step exists
and has a class that matches the Class value in this row.
History Tab Required. Description of the rule and its usage.
Transform Collection
For each infer rule processed, there is a collection containing the names of one or more
transform rules to execute. Transform collection rules are used to determine the type of

payment (method sent) based on the various patterns available. Smart Investigate for
Payments uses the FindRecTxnRef pattern in the search.
To have Smart Investigate for Payments be able to recognize new payment reference
formats, you must create a new Transform record and include it in the collection. When the
collection is processed, each format is tried until one is found. The first one found is then
executed.
To create new transform rules or modify existing ones, copy one that closely matches the
new record you want to create, save it to your ruleset, and make the appropriate changes.
Transform
The regular expression defined in a transform rule is executed against the subject text
block. It acts as a filter and allows text to pass into the Java function below if it meets the
criteria set forth in the expression. The Java transform function may then either return the
selected text, a part of it, or process it further. A return of null is considered not found and
processing within the collection continues.
For example, when searching for an amount of currency, an expression looks for a separate
group of three alphabetic characters adjacent to a group of up to 16 numeric characters
(with embedded punctuation). The amount is valid only if this pattern is found and if the
three alphabetic characters are recognized as a valid currency code. The number is then
processed t o remove all punctuation except the fraction indicator, which is set to be a
period. Only then is a result returned.
Reference IDs will most likely need to be changed, so you will need to change the Recipients
Inquiry Reference parsing rule to look for the correct ID. Smart Investigate for Payments
uses the ID to identify the case to which the incoming message applies.
To update the ID, save the transform rule named FindRecInqRef in the class PegaSI-Work-
to your ruleset. The following shows a sample FindRecInqRef transform rule.

Change the regular expression (shown below) used to filter the reference ID.
The parentheses are important, and changing them will break the current transformation.
However, you can change the contents. For the new ID, change PEG (shown in bold text in
the expression) to any three alphabetic characters. You can also create new and different
rules both in your rulesets as well as in different work classes.
Recognizing Customized Case ID and Payment Transaction Formats

The transform rule FindRecInqRef also extracts the case ID from free-form text. If you
customize case IDs, ensure that this transform record is changed accordingly.
Transaction amounts are extracted by the transform rules ValueWithCCD,

ValueWithCCD_SpaceSepAfter, and ValueWithCCDAfterDate. If you customize the payment
transaction format, ensure that these transform records are changed accordingly.

Using Regular Expressions
You can use a standard regular expression in text parsing to find a pattern.
Locating New Data Elements

The preparsed data and the responses are stored in a page type property called
ParsedData (Embed-PegaSI-MsgParseResults) in the class PegaSI-MsgCase-. To search for
an element that the Smart Investigate for Payments rules cannot locate, you can either
copy and rename an existing rule and modify its logic or create a new parsing rule.
The ParsedData contents and processing logic can be viewed from the Details Parsed Data
section of the Message Case Review screen.
Creating New Work Cases from Messages

The NewWork flow calls the CreateWorkCase flow if a message was not attached to an
existing work case during the search process; that flow calls an activity of the same name,
which determines if a work case should be opened and, if so, opens it. Smart Investigate
for Payments opens a new work case only if a PegaRESEARCH Manager query based on the
parsed data returns a single match that is not already linked to an existing work case.
The CreateWorkCase activity first calls the PaymentSearch activity, which sets up a
temporary page and calls the TransactionSearch activity. If a single unlinked match is
not found, CreateWorkCase ends and the NewWork flow continues and routes the
message for processing.
If a single match is located, the system attempts to open a work case, the class of which
is determined by the message line of business, the parsed work type, and the class of
the message case.
The parsed work type is converted into the last part of a work case class name using the
map value rule ParsedWorkTypeToClassWorkType. For example, if IAM is returned by
the parsing logic, it is converted to IncAmount (for MyCoSI-Work-Pymt-IncAmount). You
must update this map value rule to add logic for finding additional work types.
If the work type is not parsed or if the parsed work type causes an error during the add
process (for example, a required field is missing), then the system opens an Unknown
work type.
Once a case is added, the audit trail records the PegaRESEARCH Manager results and
the messages attached; the message work case should be resolved.
Unknown Work Type

The Unknown work type is a class that allows messages to open work cases even if the
exact error could not be parsed out of the text. Only the system can enter Unknown work
types, not users. The Unknown work type has two available flow actions: Change Case Type
and Resolve Investigation. The Change Case Type flow action allows the user to read the

message and manually determine what it should be. Once changed, the system executes
the standard NewWork processing for that case type. The Resolve Investigation flow action
is used on all exception work cases.
Searching For Existing Work Cases

The logic for searching for a work case is handled in the following activities:
• SearchForWorkCase — Overall search control that tries to find a case first by work
references and next by party reference. If one match is located it will open that work
case and call the existing “attach message to work case” logic.
• WorkSearchDoSearch — The activity where the details of the search based on the work
references are defined.
• WorkSearchPartyRef — The activity where the details of the search based on the party
references are defined.
The search by work references uses the following logic. A case is a match if:
The system attempts to attach a message to an existing work case only if the search logic
returns a single match; otherwise, processing moves on to the next step.
You can modify the search logic by making your own version of the noted activities.

Interface for Inbound and Outbound Messages
Smart Investigate for Payments comes prepackaged with the ability to send and receive
many different types of Fed Service and SWIFT messages, including all the common group
messages as well as the primary payment message types.
Follow the steps below to set up the interface for inbound and outbound Fed Service and
SWIFT messages. See PegaRULES Process Commander — Integrating with External Systems
for additional interface information.
Update the CLASSPATH. Add MQ Series Java components to the CLASSPATH

environment variable of the Java container application hosting the Process Commander
application. Two components must be referenced in the CLASSPATH variable:
− com.ibm.mq.jar
− connector.jar
Get MQ Server details. You will need values for the information listed below. The values
you enter must match your system values. Queue names can be anything you want to
use for identification.
− IP Address:
− Host name:
− Port:
− Channel name:
− Queue details:
Inbound: PRPC.SI.SB.INB1
Outbound: PRPC.SI.SB.OUTB1
Configure the following records:
a. For inbound messages, configure a connect MQServer rule (of type Data-Admin-
Connect-MQServer). Smart Investigate for Payments comes with a sample instance
named MQMessageSwitchServer. Update the fields with the values for your MQ
environment. One server can process both Fed Service and SWIFT messages.

b. For outbound messages, configure a connect MQ rule. The following figure shows a
sample configuration for SWIFT messages. Configure one MQ rule for Fed Service
messages and another for SWIFT messages.
c. Configure a connect MQListener rule for inbound messages. Part of the record key
for this record is the service name. This value must match the name of the
MQServer instance you created in step 3. Smart Investigate for Payments comes
with a sample instance named MyCoMQMessageSwitchListener.

Update the following fields in this record:
− Node Name — name of the node on which Smart Investigate for Payments has been
installed.
− Queue Name — name of the queue on your MQ server.
− Queue Manager — name of your Queue Manage on your MQ server.
− Password —The password as specified for the SwiftInboundAgent operator.
Configure a service MQ instance to run an activity and begin processing inbound
messages. The following figure shows an example. The Service Package, Service Class,
and Service Method fields in the previous figure make up the key for the new instance.
Complete the Primary Page and Service Activity sections. The service activity executes
when the listener collects data.

Nostro Break Feed Files
One of the sources of investigations is the Nostro Account Reconciliation system. During
the reconciliation cycle, SWIFT statements are matched with ledger statements and debits
are matched with credits. Inevitably, however, a small percentage of the debits and credits
do not have a contra entry to match against. These exceptions are typically called breaks
and at the end of the reconciliation cycle, these breaks are exported to Smart Investigate
for Payments in the form of a file for loading and investigating. Smart Investigate for
Payments comes with three predefined file listeners for receiving nostro feeds.
Follow the steps below to set up the nostro interface. See the Integration articles on the
Community for additional interface information.
Create the directory structure. Smart Investigate for Payments requires a separate
directory for each file type. The directory structure should be set up as follows:
− NostroInbound
− NewBreak
− ResolveBreak
− ValDiff
Note: The path to NostroInbound you use may be different depending upon the Web server being
used (WebSphere or WebLogic). You can use any directory in the Web server as long as you
reference the path in the Source Location field in step 2.
Configure a Connect FileListener instance for:

− NostroNewBreakFileListener
− NostroResolveBreakListener
− NostroValDiffListener
Enter the following information for your system. You can get the location and node name
from your server.
− Node name — node on which Process Commander runs.

− Source Location — directory where the appropriate input file (New Breaks, Resolved
Breaks, and Value Diffs) will be located.
− Password: — The password as specified for the NostroFileService operator.
This image is a sample of NostroNewBreakFileListener.
Click Test Connectivity to verify that the system can access the directory you specified.
Once you have verified connectivity, these file listeners will start when you restart your
application.
Inbound E-mail Interface

While Fed Service and SWIFT are the primary media for inter-bank communication, there is
also a need to correspond with corporate customers and banks that may not be part of the
Federal Reserve or SWIFT network. Historically, this has been done with telex messages and
fax messages, but today e-mail is more common. As delivered, Smart Investigate for
Payments
can receive SMTP e-mail. Attachments from inbound e-mails can be added to new message
cases and also copied to exception work objects created from message cases.

Smart Investigate for Payments does not come with sample configuration records for
inbound e- mail. Setting up inbound e-mail requires the creation of either three or five
data records, depending on whether you use a new or existing operator record.
Setting up inbound e-mail requires:
• Creating a Data-Admin-Operator-ID record (optional).

• Creating a Data-Admin-Operator-Security record (optional).
• Creating a Data-Admin-ServicePackage instance.
• Creating a Data-EmailAccount instance.
• Creating a Data-Admin-Connect-EmailListener instance.
The branch and line of business (LOB) values are determined by the address to which the e-
mail is sent. For example, PayLondon@MyCoSI.com could relate to Payment problems for
London Branch, while SecNewYork@MyCoSI.com could relate to Securities problems for
New York. You must update the processing that sets the branch and LOB values.
Follow the steps below to set up the inbound e-mail interface. See PegaRULES Process
Commander — Integrating with External Systems for additional interface information.
Set up a user with system operator privileges. This user will be the “system” operator
when the e-mail process is running. Make sure the user is configured using the
appropriate access group and other settings. You should test that you can log in as this
user, open new cases, and work on existing cases. If you can’t work on cases, then the
system won’t be able to perform work in the background either. The following images
show the screens for setting up a sample operator ID.
Set up a Data-Admin-Operator-Security instance for your operator. The following

images show the security setup for the e-mail operator ID.
Set up a Data-Admin-ServicePackage instance. The service package must use the name
EmailDefault and should reference the appropriate access group. The following images
show the setup information for the service package setup.
Configure an email account. You need to update the Data-EmailAccount rule to do this.
Ensure that you update the sender, receiver details and the host, port, and protocol for
the email account.
Set up a service email rule. Configure a Rule-Service-Email record called EmailInbound
using the settings shown in the following figures. On the Response tab, the description
values for the header fields and message data must contain the text
CreateEmailMsgCase.

Set up a Data-Admin-Connect-EmailListener instance. Configure an EmailListener
instance, for example SIDev2/SIDev2EXCHDEV. The listener name can be whatever you
want, but the server name has to be what you previously used in the EmailServer
record.
Complete the fields as described below:
• Node Name — host of the Process Commander server

• Latency Period — 10
• Maximum Number of Messages — 500
• Maximum Processing Time — 1000
• Service Method — EmailInbound (this is the name of the Rule-Service-Email instance
shipped with Smart Investigate for Payments and must be correct, as shown in the
following figure.
• Message Format — Text
• Requestor UserID — the Data-Admin-Operator-ID previously created
• Password — the password for the operator previously created
Reboot the system. Before sending messages into the system, verify that the system is
working.
− Click Test Connectivity in the Email Listener form (shown above). You should get
the response “good” if the listener is talking to your server.
− Open the Administer bar and start the System Console. Select Node Status >
Listener Status and look for the listener you created in step 6. If it tried to start and
failed, you might see a few error lines.

Outbound E-mail Interface
Follow the step below to set up the outbound e-mail interface.
Navigate to Records -> Integration –> Resources -> Email Account. A list of accounts
appears.
Select an account and click New to create a new Email Account. The following figure
shows an example.
− The account name is any unique name of your choice. Start with a letter and use
only alphanumeric characters.
− The account type is another unique name starting with a letter and containing only
letters and digits.
Note: Do not delete the system default e-mail account, named Default.
Accounting Feed Posting File

Smart Investigate for Payments maintains a database table of all debit and credit
accounting entries that have been verified and released for posting to external accounting
systems. Listed in order by posting date, each entry is written to the PAF_Entry database
table. See online for instructions on how to view the schema.
The writing of entries to this table is not enabled when Smart Investigate for Payments is
installed. The standard product is configured to use outgoing Fed Service and SWIFT
messages and other correspondence as the posting instruments. To enable this function,

select the Use Documents For Posting box on the Options tab of each Payment Type
record you want to use for posting debits and credits.
When entries are written, all columns in this table, except ExtractDateTime, are populated
by the system and are read only. The ExtractDateTime column exists so that processes
extracting rows from the table can mark those rows with a date/time value to indicate
when they were extracted. By marking records that have already been extracted, you are
able to feed multiple accounting systems multiple times each day. Subsequent runs of the
feed can ignore rows where ExtractDateTime is not null. Using this value with other
columns such as AccountType, which is an indicator of an external accounting system like
DDA or GL, an extraction process can further select and sort the appropriate rows for the
accounting system you are feeding.
To implement a real-time or batch accounting feed, you must write a program or script to
extract data from the database. The process you implement to extract the data from the
table is your choice. See the Integration articles on the PDN for your connectivity options.
Customer Information File Interface

As delivered, Smart Investigate for Payments provides a relational database table,
PCB_Accounts, to store customer information data together with the SQL to query the data.
This database may be used in production as is, in which case it would be necessary to
create a feed process that updates the table periodically with new, updated, and deleted
records. There is also a customer information record maintenance function available with
Smart Investigate for Payments to enable the data to be maintained manually rather than
wait for updates to arrive from the primary CIF application.
If you prefer to use an existing CIF, Smart Investigate for Payments provides placeholder
activities that can be copied and modified to enable the lookup and retrieval of customer
account information from your centralized customer information database files. Based on
the entry of a customer’s account number and account type, the lookup validates and
returns a customer’s account name, account address, contact, and preference information.
When retrieved, this information is placed on the clipboard and subsequently mapped into
a customer party in a Smart Investigate for Payments case.
To create your CIF interface, select your connectivity method and determine your field
mapping between the data source and Smart Investigate for Payments. Then, create and
modify versions of the following activities to map and validate the data:
• PegaSI-Party Lookup — This activity looks up the customer account information in the
database and sets the properties on the clipboard.
• PegaSI-Party Validate — This activity validates the customer’s account number and
account type on entry.
Smart Investigate for Payments Data Tables and Views
The following table lists the Smart Investigate for Payments data tables and views. Tables
identified as PegaRESEARCH Manager tables are created and loaded during the Smart
Investigate for Payments installation process, but also must be loaded into PegaRESEARCH
Manager. When you load these tables into PegaRESEARCH Manager they are identical
except that they are placed in a separate database.
Using the interface activities described in this chapter, map your data to these tables.
Table Name Description

PA_Product This table is required by the PegApp layer but is not used by Smart
Investigate for Payments.
PA_Product_Type This table is required by the PegApp layer but is not used by Smart
PAF_Entry This table prepares the Smart Investigate for Payments
accounting entries for posting to an external system.
PAF_Index_Original This table indexes the original data from Smart Investigate for
Payments for reporting and cannot be modified.
PAF_Index_Txn This table indexes the Smart Investigate for Payments
accounting data for reporting and cannot be modified.
PAF_Index_Workparty This table indexes the Smart Investigate for Payments work items for
reporting and cannot be modified.
PAF_Party This table holds the Smart Investigate for Payments internal account
records.
PAF_Work This is the Smart Investigate for Payments work object table and holds
case data. When first installed it contains sample data.
PAF_Rule This is the Smart Investigate for Payments financial rules table.
PCB_Accounts This is the Smart Investigate for Payments party table.

SI_Index_AdjustmentDetails This table is used for financial / accounting reports.
SI_Work This is the default table for Smart Investigate for Payments work
objects.
SI_Index_Workparty This table is an index listing of each party associated with a work
object.

SI_SecurityLevel SI_OperatorSecurity These tables contain Smart Investigate for Payments security
configuration records. These tables augment the Smart Investigate
for Payments security and are in addition
to standard Process Commander security.
SIV_AdjusmentDetails 30. This table is used for Financial / Accounting reports.
SIV_CaseFind This database view joins SI-Work and SI_Index_WorkParty
to allow comprehensive case find capabilities within Smart
SIV_Workbasket This database view facilitates reports based on workbaskets.
SIV_Worklist This database view facilitates reports based on worklists.
Research_Links This table stores transaction data and is a PegaRESEARCH Manager
table.
AdditionalPymtInfo This table stores transaction data and is a PegaRESEARCH Manager
table.
History This table stores transaction data and is a PegaRESEARCH Manager
table.
InterestRates This table stores the interest rates for interest rate table
maintenance.
LoadStat This table stores transaction data and is a PegaRESEARCH Manager
table.
Message This table stores transaction data and is a PegaRESEARCH Manager
table.
PaymentCharges This table stores transaction data and is a PegaRESEARCH Manager
table.
PaymentTxn This table stores transaction data and is a PegaRESEARCH Manager
table.
Security This table stores transaction data and is a PegaRESEARCH Manager
table.
Settlement This table stores transaction data and is a PegaRESEARCH Manager
table.
WorkActions This table is used for MIS reports.
Pega 8 Integration Layer

A new integration layer and data page rules are introduced in Pega7 Smart Investigate
release. Prior to Smart Investigate 7
• A separate database integration layer was not defined.

• Data from the database was fetched directly via connect-SQL rules making it tightly
coupled with the application.
• New set of connect-SQL rules had to be defined in the application to extend the support
for new databases.
Starting Smart Investigate 7x
• A new pluggable database integration layer has been added for easy implementation.
• Data from the database is fetched via Data Pages through Report Definition rules.
• With Report Definition rules, the troublesome approach of creating new connect-SQL
rules for new database is eliminated, making the application loosely coupled with
Database.
As part of the integration layer Connect-SQL rules in Smart Investigate Layer have been
converted to Report definitions referred through Data pages.
Ideally Integration class is required if data is read from external system. We don’t need the
data integration layer if the if data is populated during runtime in database table or If the
framework is designed for mapping data class layer with database layer for storing data
(for example: Data- Admin-Operator-Security class instances are directly stored in DB
table)
Following are the list of Smart Investigate Database tables considered for adding
Integration layer in the Framework.
• Research Manager Layer

− ADDITIONALPYMTINFO
− HISTORY
− MESSAGE
− PAYMENTCHARGES
− PAYMENTTXN
• Payments Layer
− PCB_ACCOUNTS
− INTERESTRATES
• Securities Layer
− SECURITY
− SETTLEMENT

High level Implementation Approach for Data Page
conversion
This section describes a high level approach that you can take to implement a data page
conversion.
Retrieve data from Database

Create report definitions on the integration class in the PegaSIINT ruleset
Create data in a Data Class in the FW ruleset.
Configure a report definition as the data source in a Data Page
Use a data transform to map the Integration Layer properties to Data Layer properties.
a. Data transform rule - “OpenMap” is the FW OOTB Naming convention to map int
layer properties to Data layer properties invoked based on the class name.
b. Create the data transform in a Data class in FW rule set
Update the SQL/RDB referenced activities with data transforms to invoke the Data
Pages.
Write data to Database

To write back data to database, Obj methods through activity rules are needed, as there
are no equivalent methods for Save and Delete from Data Pages.
Create a temporary page of respective integration class type.
Hold/Set the properties and its corresponding values on the temporary page
a. Data transform rule - SaveMap is the the out of the boxnaming convention to map
Data layer properties to Integration layer properties invoked based on the data
layer class name.
b. Create the data transform rule in Data class in FW rule set
Call the wizard generated activity rule named SaveXXXXXXX (eg: SaveINTERESTRATES) to
save the data back to database which uses Obj methods instead of RDB methods.
Data Page Reference Implementation for retrieving the data

The following is the reference implementation of the Data Page for the table
INTERESTRATES With the old approach to retrieve data from DB to work layer, database
specific Connect-SQL rule is required. See the image below for an example.

With the new approach, a Data Page is invoked via data transform rule to retrieve the data.
The Data Page fetches the data from database through report definition.
The report definition would automatically build the select statement and where clauses
regardless of database configured. See the example below.

Referencing the implementation to write data
With the old approach database a Connect-SQL rule was required that references an RDB-
Save method to write the data from/ to the DB layer.
These images show an example of that approach.

With the new approach a data transform is created to map the Data class properties to the
NT layer properties.
These images show examples of the new data transform approach.

The following lists the activities updated in the framework layer to add data pages.
• SingleInterestRate
• DeleteInterestRateNGP
• SaveToDB
• SingleInterestRateAdd
• UpdateInterestRate
• BrowseADDITIONALPYMTINFO
• DeleteADDITIONALPYMTINFO
• OpenADDITIONALPYMTINFO
• SaveADDITIONALPYMTINFO
• BrowseHISTORY
• DeleteHISTORY
• OpenHISTORY
• SaveHISTORY
• BrowseINTERESTRATES
• DeleteINTERESTRATES
• OpenINTERESTRATES
• SaveINTERESTRATES
• BrowseMESSAGE
• DeleteMESSAGE
• OpenMESSAGE
• SaveMESSAGE
• BrowsePAYMENTCHARGES
• DeletePAYMENTCHARGES
• OpenPAYMENTCHARGES

• SavePAYMENTCHARGES
• BrowsePAYMENTTXN
• DeletePAYMENTTXN
• OpenPAYMENTTXN
• SavePAYMENTTXN
• BrowsePCB_ACCOUNTS
• DeletePCB_ACCOUNTS
• OpenPCB_ACCOUNTS
• SavePCB_ACCOUNTS
• BrowseSECURITY
• DeleteSECURITY
• OpenSECURITY
• SaveSECURITY
• BrowseSETTLEMENT
• DeleteSETTLEMENT
• OpenSETTLEMENT
• SaveSETTLEMENT
• InterestRateMaintenanceSearch
• SICalculateIntRates

Understanding Reports and Report
Scheduling
In addition to the standard Pega 8 reports, Smart Investigate for Payments captures
information during the processing of messages and cases that has been translated into
several types of reports to assist managers and administrators in the monitoring and
management of financial transactions, operator productivity and message reconciliation.
These reports fall into the following categories:
• MIS Reports — Summary information related to inventory management, efficiency and

productivity
• Financial Reports — Summary information related to accounting adjustments and the
payment and receipt of compensation
• Message Reconciliation Reports — Lists of messages that have been sent and received
for reconciliation purposes
• Compensation Reports—Lists of the compensation cases that are pending, resolved and
open indemnities.
A Schedule Reports option is also available that enables a user to automatically generate
and distribute Smart Investigate reports on a pre-defined schedule.
Smart Investigate reports are displayed in the Report Browser of the System Administrator
portal and the Reports tab of the Manager’s portal.
The list of reports belonging to each report category is displayed as below.

The data in these reports can be exported to Microsoft Excel. Reports created as a
Summary View or List View can be customized by using the Report wizard to modify
selected report elements. These reports also provide examples you can copy to create new
reports that meet your organization’s needs.
MIS Reports
The following is a list and description of the MIS reports located under the MIS Reports tab
in the Reports workspace.
Report Name: Reopened Case Report By Operator
Class and Rule Name: PegaSI-Data-WorkAction.SIReopenedSummary
Description: Report summary of the number of cases reopened by operator with graphic
display and drill down capability by operator to review and display individual reopened
cases
Report Name: Repaired Case Report by Operator QR
Class and Rule Name: PegaSI-Data-WorkAction.SIRepairedSummary
Description: Report Summary of the number of cases repaired by operator with graphic
display and drill down capability by operator to review and display individual repaired cases
Report Name: Cancelled Case Report by Operator
Class and Rule Name: PegaSI-Data-WorkAction.SICancelledSummary

Description: Report summary of the number of cases cancelled by operator with graphic
display and drill down capability by operator to review and display individual cancelled
cases
Report Name: Quality Review Report by Operator QR
Class and Rule Name: PegaSI-Data-WorkAction.SIQRSummary
Description: Report Summary of the number cases reviewed for quality by operator with
graphic display and drill down capability by operator to review and display individual
reopened cases.
Financial Reports
The following is a list and description of the Financial reports located under the Financial
Reports tab of the Reports workspace.
Report Name: Accounting AdjustmentsTotals by Date and Currency
Class and Rule Name: PegaSI-Data-AdjustmentDetails.AdjustmentsDetailByDateByCurrency
Description: Report summary of the total amount of adjustments grouped by adjustment

date and currency within each date; drill down capability to review and display individual
cases and accounting activity; user prompted for entry of adjustment date range.
Report Name: Compensation Paid by Date and Currency
Class and Rule Name: PegaSI-Data-AdjustmentDetails.CompensationPaidByDateByCurrency
Description: Report summary of total amount of compensation paid grouped by

adjustment ate and currency with each date; drill down capability to review and display
individual cases and accounting activity; user prompted for entry of adjustment date range.
Report Name: Compensation Received by Date and Currency
Class and Rule Name: PegaSI-Data-

AdjustmentDetails.CompensationReceivedByDateByCurrency
Description: Report summary of total amount of compensation received grouped by

adjustment date and currency within each date; drill down capability to review and display
individual cases and accounting activity; user prompted for entry of adjustment date range
Report Name: Pending Compensation Payments by Currency

AdjustmentDetails.PendingCompensationClaimsByDateByCurrency

Description: Report summary of total amount of compensation claims pending outgoing
payment grouped by adjustment date and currency within each date; graphic display and
drill down capability to review and display individual cases and accounting activity.
Report Name: Pending Compensation Receipts by Currency

AdjustmentDetails.PendingCompensationReceiptByDateByCurrency
Description: Report summary of total amount of compensation claims pending receipt of

payment grouped by adjustment date and currency within each date; drill down capability
to review and display individual cases and accounting activity.
Message Reconciliation Reports

The following is a list and description of the reports listed under the Message Reconciliation
tab of the Reports workspace.
Report Name: Incoming Message Reconciliation
Class and Rule Name: SIPromptMessageReconIncoming
Description: Incoming messages report by message date that displays the case ID,
message date and type, and the receiver’s address; drill down capability to review and
display individual cases; user prompted for entry of message date range.
Compensation Reports
Report Name: Open Indemnities
Class and Rule Name: OpenIndemnityCases
Description: Report of the open indemnity cases by case ID, TransactionDate, Indemnity.
Direction drill down capability to review and display individual cases; user prompted for
entry of Transaction Date.
Report Name: Pending Compensation Cases
Class and Rule Name: PendingCompensationCases
Description: Report of the pending compensation cases by Case ID, Status, Total
Compensation Amount, Transaction Date; drill down capability to review and display
individual cases; user prompted for entry of transaction date range
Report Name: Resolved Compensation Cases
Class and Rule Name: ResolvedCompensationCasess

Description: Report of the pending compensation cases by Case ID, Status, Total
Compensation Amount, Transaction Date; drill down capability to review and display
individual cases; user prompted for entry of transaction date range
Using the Schedule Report Function

Smart Investigate includes a Data-Gadget that you can place on a user portal that allows
that user to schedule and distribute reports at defined intervals. This feature of scheduling
reports can be done from the Manager’s portal.
To schedule a report:
Login to system using SIManager@pega.com & the updated password

Select Reports from left navigation pane.
Select the report from the report categories which need to be scheduled and click the
gear button next to it. Click schedule.

The New Schedule Report form appears in your workspace.
Enter the following information.

a. Enter the task schedule details.
b. Enter the task Output Processing details
c. Configure the Notification Message details
Click Submit.
For the scheduled report, the Email notification status would be updated to Scheduled
and Subscribed.

To cancel a scheduled report:
Click on the gear icon and select the unsubscribe option.
The Unsubscribe Report form appears in your workspace.

Click Unsubscribe.
Adding Reports to the Scheduler

You can easily add reports to the selection list of the schedule form by creating a report.
The Report Scheduler is constructed to automatically retrieve reports from the database
and display them in the selection list reports that meet the following naming criteria.
• List View reports created in a class with MyCoSI included in the class name and do not
have CaseFind in its pyStreamName.
• Summary View reports created in a class with MyCoSI, Assign, or PegaSI-Worklist in the
class name and do not have CaseFind in its pyStreamName.

Appendix A: Application-Specific
Information
This appendix contains application-specific details that are referenced in Chapters 2 through 7.
• System administrator account information

• Smart Investigate for Payments rulesets
• Work object naming conventions
• Remaining in verification queue
• Default workbaskets and worklists
• Default operators and access groups
• Predefined access roles and privileges
• Predefined organization, divisions, and units
• Default portal layouts
• Correspondence templates
• Structured correspondence templates
• Sample data
System Administrator Account

Smart Investigate for Payments uses the following operator ID as the default system
administrator account. Enter the password that you specified. Below Operator ID is shipped as
part of Pega Smart Investigate for Sample layer.
Operator ID: SIPaymentsDev@pega.com
Smart Investigate for Payments RuleSets

The following figure shows your Smart Investigate for Payments RuleSet hierarchy, highest to
lowest.
Pega Smart Investigate for Payments Implementation Guide A-1

Work Object Naming Conventions
Each work object has a unique ID which is computed by combining a system-assigned number
and a prefix defined in a map value rule. The following prefixes are defined in Smart Investigate
for Payments:
• M- — defined in the PegaSI-Work class and used to identify message cases.

• PEG — defined in the MyCoSI-Work class and used to identify exception cases.
• CMP — defined in the MyCoSI-Work class and used to identify compensation cases.
• CVR — defined in the MyCoSI-Work class and used to identify bulk-entry payments cases.
Note: The PEG, CMP, and CVR identifiers do not include a dash so that the ID does not exceed the 16-
character limit for SWIFT reference numbers.
Default Work Groups, Workbaskets, and Worklists

The following table lists the default work groups, workbaskets, and worklists.
Work Groups

Default
Worklists
SIManager SISysAdmin
SIReview SIUser1
SISecAdmin SIUser2
SISupervisor
General Workbaskets in PegaSI
SI Case Workbaskets Nostro Workbaskets Payment Workbaskets
SICaseEntry InMsgNostro InMsgPayments
SIDuplicates NOSAcctRepair PAYAcctRepair
SIExceptions NOSAcctVerify PAYAcctVerify
SIPendingCorrResponse NOSAcctVerifyL2 PAYAcctVerifyL2
SIBulkCaseEntry NOSCorrRepair PAYCorrRepair
AppCorrPendingCorrRespon NOSCorrVerify PAYCorrVerify
AppCorrPendingVerification NOSCorrVerifyL2 PAYCorrVerifyL2
NOSCompensation PAYCompensation
Securities Case NOSCompAcctRepair PAYCompAcctRepair
SecCorrRepair NOSCompAcctVerify PAYCompAcctVerify
SecCorrVerify NOSCompAcctVerifyL2 PAYCompAcctVerifyL2
SecCorrVerifyL2 NOSCompCorrRepair
NOSCompCorrVerify PAYCompCorrVerify
NOSTRO - Indemnities PAYMENTS - Indemnities
NOSTRO – CashReporting
Divisional Workbaskets in PegaSI
APAC Division
APFXMSGCases APPAMSGCases APSEMSGCases APSECAMSGCases
APFXREPCases APPAREPCases APSEREPCases APSECAREPCases
APFXVFYCorr1 APPAVFYCorr1 APSEVFYCorr1 APSECAVFYCorr1
APFXWRKCases APPAWRKCases APSEWRKCases APSECAWRKCases
APSEGNMSGCases APSEINAMSGCases APSENRMSGCases APSESDMSGCases
APSEGNREPCases APSEINAREPCases APSENRREPCases APSESDREPCases
APSEGNVFYCorr1 APSEINVFYCorr1 APSENRVFYCorr1 APSESDVFYCorr1
APSEGNWRKCases APSEINWRKCases APSENRWRKCases APSESDWRKCases
APSESRMSGCases APSESTMSGCases APSETAMSGCases APTRMSGCases
APSESRREPCases APSESTREPCases APSETAREPCases APTRREPCases
APSESRVFYCorr1 APSESTVFYCorr1 APSETAVFYCorr1 APTRVFYCorr1
APSESRWRKCases APSESTWRKCases APSETAWRKCases APTRWRKCases
ACRPTCases
ASIA Division
ASFXMSGCases ASPAMSGCases ASSEMSGCases ASTRMSGCases
ASFXREPCases ASPAREPCases ASSEREPCases ASTRREPCases
ASFXVFYCorr1 ASPAVFYCorr1 ASSEVFYCorr1 ASTRVFYCorr1
ASFXWRKCases ASPAWRKCases ASSEWRKCases ASTRWRKCases
ASRPTCases (default)

EMEA Division
EMFXMSGCases EMPAMSGCases EMSEMSGCases EMTRMSGCases
EMFXREPCases EMPAREPCases EMSEREPCases EMTRREPCases
EMFXVFYCorr1 EMPAVFYCorr1 EMSEVFYCorr1 EMTRVFYCorr1
EMFXWRKCases EMPAWRKCases EMSEWRKCases EMTRWRKCases
EMRPTCases
LACD Division
LAFXMSGCases LAPAMSGCases LASEMSGCases LATRMSGCases
LAFXREPCases LAPAREPCases LASEREPCases LATRREPCases
LAFXVFYCorr1 LAPAVFYCorr1 LASEVFYCorr1 LATRVFYCorr1
LAFXWRKCases LAPAWRKCases LASEWRKCases LATRWRKCases
LARPTCases (default)
Remaining in Verification Queue

Verification queues can be configured to allow operators to remain in the queue and sequentially
verify each item in the queue, rather than ending on the Review Harness after each verification
step and having to return to the portal to select the queue for the next item. The system will skip
items that an operator is not authorized to verify, if he/she created the item for example. To
configure queues to enable this new processing, update the Decision Table,
IsLastAssgnProcessedFromVfyWB to include or exclude specific workbaskets:
Default Operators and Access Groups

Smart Investigate for Payments ships with the operators and access groups listed in the following
table (with passwords as specified). Below Operators ID are shipped as part of Pega Smart
Investigate for Payments Sample layer.

Operator Access Group
SIPaymentsDev@pega.com SISysAdmin
SIManager@pega.com SIManager
SIReview@pega.com SIReview
SISecAdmin@pega.com SISecAdmin
SISupervisor@pega.com SISupervisor
SISysAdmin@pega.com SISysAdminSample
SIUser1@pega.com SIUser1
SIUser2@pega.com SIUser2
Predefined Access Roles and Privileges

Your application includes a set of predefined access roles and privileges. If you need to create
your own privileges, see Chapter 5 for more information about privileges.
The following table shows Smart Investigate for Payments roles and associated privileges.
Note: SIReview and SISecAdmin do not have predefined privileges.
Roles
Privileges SIDeclarePagesAccess
SISupervisor
SISysAdmin
SISecAdmin
SIReview
SIUser1
SIUser2
Exception Case Flow Actions

StepByStep Flow
DetachMessage X X X X X X
ReviewMessage X X X X X X
DuplicateSearchSBS X X X X X X
Send_Messages X X X X X X
ResolveCase X X X X X X
StartAdjustment X X X X X X
ResearchManager X X X X X X
EmbedMessageCaseFind X X X X X X
EmbedExceptionCaseFind X X X X X X
Transfer X X X X X X
TransferToManager X X X X X X
TransferToWorkbasket X X X X X X
UpdateServiceInfo X X X X X X
StartAdjustment X X X X X X

CopyCaseID X X X X X X
ManualResearch Flow
PerformResearch X X X X X X
ResearchComplete X X X X X X
StepByStep X X X X X X
ProcessAdjustmentSTP
Flow
ReviewAccountingFailure X X X X X X
InitalProcessing Flow
CompleteEntry X X X X X X
DuplicateSearch Flow
AppDupResults X X X X X X
SwiftCorrCreate Flow
CancelSwiftCreate X X X X X X
CreateSwiftMessage X X X X X X
AbandonSwiftMessageCrea X X X X X X
te
AppCorrCreate Flow
CorrProcess X X X X X X
CorrCancel X X X X X X
Message Case Flow Actions
StepByStep Flow
CreateWorkCase X X X X X X
AttachMessageToWorkCase X X X X X X
CancelMessage X X X X X X
UpdateMessage X X X X X X
TransferToWorkBasket X X X X X X
EmbedExceptionCaseFind X X X X X X
EmbedMessageCaseFind X X X X X X
ResearchManager X X X X X X
Accounting Specific Security

Adjustment X X X X X X
CutoffCancel X X
CutoffForce X X
CutoffRelease X X

VerifyLevel1 X X X X X
VerifyLevel2 X X X X
VerifyLevel3 X X X
Portal Layouts –
The tabs and tab names that you see on your home page (or portals) when you log in are defined
in access groups. Smart Investigate for Payments ships with the following instances of portal
rules:
• SIUser1 (SIUser1 and SIUser2 operators and access groups)

• SIManager (SIManager operators and access groups)
• SISecAdmin (SISecAdmin operator and access group)
SI User
The following shows the SI User portal layout.
SI Manager
The following shows the SI Manager portal layout.

SI System Administrator
The following shows the SI system administrator portal layout (Developer Portal).
Service Level Rules and Escalation Activities

Smart Investigate for Payments includes a set of predefined service level rules and escalation
activities.

Service Levels
Service Levels Description
SIMessageReview Referenced by the MessageAttached assignment of the
SIMessageSBS Referenced by the ProcessMessage assignment of theStepByStep
SIDuplicates Referenced by the ProcessPotentialDuplicates assignment of the

DuplicateSearch flow
SIRepair Referenced by the Repair assignment of the AcctgRepair flow and
AppCorrVfy Reference by the VerifyCorrespondence and SecondVerification

assignments of the AppCorrVerify flow and at deadline time calls
Escalation Activities
Escalation Activity Description
SendEmailToOwner Sends mail to assignee. Called by service level SIRepair
SendEmailToCreator Sends email to assignee. Called by service level AppCorrVfy
Correspondence Templates
Smart Investigate for Payments comes with a standard set of sample correspondence templates.
The following table lists the templates that are specific to the processing of Smart Investigate for
Payments workflows (all defined under Rule-PegaCommBank-Corr). The following table lists
other generic samples that ship with the application and can also be used as references for
building correspondence.
Smart Investigate for Payments Correspondence Templates
Class Name Stream Name Type Description

PegaSI-Work- Adviceblankltr Mail, English Advice blank letter
Adviceblankemail E-mail, English Advice e-mail — free format
PegaSI-Work- Mailfreeformat Mail, English Free format mail

Emailfreeformat E-mail, English Free format e-mail

Class Name Stream Name Type Description
PegaSI-Work- Replytoincominginquiry Mail/E-mail, Reply to incoming inquiry
Replytoincominginquiry English acknowledgement
PegaSI-Work- Replytoincominginquiryack Mail/E-mail, Reply to incoming inquiry and

Replytoincominginquiryack English acknowledgement
PegaSI-Work- Unabletoapplyinquiry Mail/E-mail, Unable to apply inquiry

English
PegaSIPymt-Work- Regardingcustpay Mail/E-mail, Receiving bank outbound
English customer
PegaSIPymt-Work- BCNR Custpaymentbenenonreceipt Mail/E-mail, Receiving bank — outbound
English payment — beneficiary non
receipt
PegaSIPymt-Work- Requestforcharges Mail/E-mail, Your payment request for
Corrbkchg English charges
PegaSIPymt-Work- IncDate Custpaymentlatepyt Mail/E-mail, Receiving bank — outbound
English payment — ensure
beneficiary receives good
PegaSIPymt-Work- Remitbankpayunableeffectpyt Mail/E-mail, Remitting bank — their
Utepay English payment
to us — request for further
info
Smart Investigate for Payments Accounting Templates

Class Name Stream Name Type Label
PegaSI-Work- Adviceblank199 MT199 Free Format Advice via 199
PegaSI-Work- Adviceinqbnf999 MT999 Advice to Inquirer via 999, Re: Bene
PegaSI-Work- Adviceinqcr999 MT999 Advice to Inquirer via 999, Re: Credit
PegaSI-Work- Adviceinqnewbnf999 MT999 Advice to Inquirer via 999, Re: New
PegaSI-Work- Adviceinqrem999 MT999 Advice to Inquirer via 999, Re:
PegaSI-Work- Adviceinqsbk999 MT999 Advice to Inquirer via 999, Re:
PegaSI-Work- Adviceofcr MT199, 299, 999 Advice of Credit
PegaSI-Work- Adviceofdr MT199, 299, 999 Advice of Debit
PegaSI-Work- Adviceofpay MT199, 299, 999 Advice of Payment
PegaSI-Work- Dcus1cwash103 MT103 Dr Customer1, Cr Wash, via 103
PegaSI-Work- Dcusblank103 MT103 Dr Customer, Cr Select, via 103

Class Name Stream Name Type Label
PegaSI-Work- Dcusblank202 MT202 Dr Customer, Cr Select, via 202
PegaSI-Work- Dcusbnf103 MT103 Dr Customer, Beneficiary, via 103
PegaSI-Work- Dcusbnf202 MT202 Dr Customer, Beneficiary, via 202
PegaSI-Work- Dcusccus103 MT103 Dr Customer, Cr Customer, via 103
PegaSI-Work- Dcusccus202 MT202 Dr Customer, Cr Customer, via 202
PegaSI-Work- Dcuscwash103 MT103 Dr Customer, Cr Wash, via 103
PegaSI-Work- Dcuscwash202 MT202 Dr Customer, Cr Wash, via 202
PegaSI-Work- Dcusnewbnf103 MT103 Dr Customer, New Beneficiary, via 103
PegaSI-Work- Dcusnewbnf202 MT202 Dr Customer, New Beneficiary, via 202
PegaSI-Work- Dcusrbk202 MT202 Dr Customer, Receiving Bank, via 202
PegaSI-Work- Dcusrem103 MT103 Dr Customer, Remitter, via 103
PegaSI-Work- Dcusrem202 MT202 Dr Customer, Remitter, via 202
PegaSI-Work- Dcussbk103 MT103 Dr Customer, Sending Bank, via 103
PegaSI-Work- Dcussbk202 MT202 Dr Customer, Sending Bank, via 202
PegaSI-Work- Dwashccus103 MT103 Dr Wash, Cr Customer via 103
PegaSI-Work- Dwashccus1103 MT103 Dr Wash, Cr Customer1, via 103
PegaSI-Work- Dwashccus202 MT202 Dr Wash, Cr Customer, via 202
SWIFT Correspondence Templates

Smart Investigate for Payments ships with the correspondence templates described below,
which are used during SWIFT processing.
Class Name Template Message Type Description

PegaSI-Work- AutoAck MT199 Auto acknowledgement to
Inquirer
PegaSIPymt- Work- CancelCoverPay MT292 Request cancellation of our
cover payment
PegaSIPymt- CancelPayOrder MT192, 292 Request cancellation of our
payment
PegaSI-Work- ChargesTakenFreeFormat MT190, 290 Advise details of charges
PegaSIPymt- CoverPaymentAmendBene MT295, 299 Corr bank — outbound
cover
PegaSIPymt- CoverPaymentBeneNonReceipt MT295, 299. Corr bank — outbound
cover

PegaSIPymt- Work- CoverPaymentCancellation1 MT295, 299 Corr bank — outbound cover

Cancel payment — request for debit
PegaSIPymt- CoverPaymentCancellation2 MT295, 299 Corr bank — outbound cover
PegaSIPymt- Work- CoverPaymentCancellation3 MT295, 299 Corr bank — outbound cover

Cancel
payment — return funds via
PegaSIPymt- Work-Dup CoverPaymentDupPyt1 MT295, 299 Corr bank — outbound cover
payment — request debit

payment — request to be
payment — request for refund

PegaSIPymt- Work- CoverPaymentEarlyPyt1 MT295, 299 Corr bank — outbound cover
IncDate
payment — adjust value of
IncDate payment — request authority
to
IncDate
payment — request authority
PegaSIPymt- Work- CoverPaymentIncorrectBkPaid1 MT295, 299 Corr bank — outbound cover
IncBank
payment — incorrect bank —
IncBank
payment — incorrect bank —
IncBank payment — return funds via
corr
PegaSIPymt- CoverPaymentIncorrectBkPaid4 MT295, 299 Corr bank — outbound cover
PegaSIPymt- CoverPaymentIncorrectCreditAcc MT295, 299 Corr bank — outbound cover
PegaSIPymt- Work- CoverPaymentLatePyt MT295, 299, Corr bank — outbound cover

IncDate
995, 999 payment — ensure beneficiary

PegaSIPymt- Work- CoverPaymentNostroLedgerCredi t MT295, 299, Corr bank — outbound cover

payment — advise details of
NostroLdgCr 995, 999 your
PegaSIPymt- Work- CoverPaymentWrongCoverOut MT295, 299 Corr bank — outbound cover
IncCvr
payment — advice to confirm
PegaSIPymt- Work- CustPaymentAmendBene MT195, 299, Receiving bank — outbound
AmendBen payment
PegaSIPymt- Work- CustPaymentBeneNonReceipt MT195,199, Receiving bank — outbound
BCNR 295, 299, payment
PegaSIPymt- Work- CustPaymentCancellationReques t1 MT195, 199, Receiving bank — outbound

Cancel payment
295, 299
PegaSIPymt- CustPaymentCancellationReques MT195, 199, Receiving bank — outbound
payment
PegaSIPymt- CustPaymentCancellationReques MT195, 199, Receiving bank — outbound
payment
PegaSIPymt- CustPaymentDupPyt1 MT195, 199, Receiving bank — outbound
payment
PegaSIPymt- Work- CustPaymentDupPyt2 MT195, 199, Receiving bank — outbound
Dup payment
PegaSIPymt- Work- CustPaymentDupPyt3 MT195, 199, Receiving bank — outbound
Dup payment
295, 299
PegaSIPymt- Work- CustPaymentEarlyPyt1 MT195, 199, Receiving bank — outbound
IncDate payment
295, 299
PegaSIPymt- Work- CustPaymentEarlyPyt2 MT195, 199, Receiving bank — outbound
IncDate payment
295, 299
PegaSIPymt- CustPaymentEarlyPyt3 MT195, 199, Receiving bank — outbound
payment
PegaSIPymt- Work- CustPaymentIncorrectBk1 MT195, 199, Receiving bank — outbound
IncBank payment
295, 299
IncBank payment
295, 299
IncBank payment
295, 299


IncBank payment
295, 299
PegaSIPymt- CustPaymentIncorrectCharges1 MT195, 199, Receiving bank — outbound
payment
PegaSIPymt- CustPaymentIncorrectCharges2 MT195, 199, Receiving bank — outbound
payment
PegaSIPymt- Work- CustPaymentIncorrectCreditAcc MT195, 199, Receiving bank — outbound
IncCrAcct payment
PegaSIPymt- Work- CustPaymentIncorrectCurrency MT195, 199, Receiving bank — outbound
IncAmount payment
295, 299
PegaSIPymt- Work- CustPaymentLatePyt MT195, 199, Receiving bank — outbound
IncDate payment
295, 299,
PegaSIPymt- Work- CustPaymentNostroLedgerCredit MT195, 199, Receiving bank — outbound
payment
NostroLdgCr 295, 299,
PegaSIPymt- CustPaymentNostroValDiff MT195, 199, Receiving bank — outbound
payment
Work- NostroValDif 295, 299,
PegaSIPymt- CustPaymentOverpayment MT195, 199, Receiving bank — outbound
payment
PegaSIPymt- Work- CustPaymentUnderpayment1 MT195, 199, Receiving bank — outbound
IncAmount payment
295, 299
IncAmount payment
295, 299
IncAmount payment
295, 299
PegaSIPymt- Work-IncCvr CustPaymentWrongCoverOut MT295, 299 Receiving bank — outbound
payment
PegaSI-Work- GenFreeFormat1 MT195, 295, General purpose, free format
195 —
PegaSI-Work- GenFreeFormat2 MT195, 295. General purpose, free format
195 — without code
PegaSI-Work- InquiryResponseFreeFormat1 MT196, 296, Response to incoming inquiry
— with
PegaSI-Work- InquiryResponseFreeFormat2 MT196, 296, Response to incoming inquiry
—

PegaSIPymt- RegardingCoverPayment MT299 Corr bank - outbound cover

payment
PegaSIPymt- RegardingCoverPayment1 MT195, 295, Corr bank - outbound cover
payment
PegaSIPymt- RegardingCoverPayment2 MT195, 295, Corr bank - outbound cover
payment
PegaSIPymt- RegardingCustPayment MT199, 299, Receiving bank — outbound
payment
PegaSIPymt- Work- RegardingCustPayment1 MT195, 295, Rec bank — outbound
customer payment — with
PegaSIPymt- RegardingCustPayment2 MT195, 295, Rec bank — outbound
customer
PegaSIPymt- Work- RegardingRemitBankPay MT199, 299, Remitting bank — their
payment to us — free format
PegaSIPymt- RegardingRemitBankPay1 MT195, 295, Remitting bank — their
payment to
PegaSIPymt- RegardingRemitBankPay2 MT195, 295, Remitting bank — their
payment to
PegaSIPymt- Work-Dup RemitBankPayDupPyt MT195, 295, Remitting bank — their
payment to us — confirm if
995 payment to be
PegaSIPymt- Work-Dup RemitBankPayDupPyt MT199, 299, Remitting bank - their payment
to us
PegaSIPymt- Work- RemitBankPayLatePyt MT199, 299, Remitting bank — your
IncDate payment to
999
PegaSIPymt- Work- RemitBankPayNostroLedger MT195, 199, Remitting bank — their
Debit payment to us — request
NostroLdgDr 295, 299, details of their credit
PegaSIPymt- Work- RemitBankPayNostroValDiff MT195, 199, Remitting bank — their
payment to us — request for
NostroValDif 295, 299, good value
PegaSIPymt- Work- RemitBankPayOverpayment MT195, 199, Remitting bank — their
IncAmount payment to us
295, 299,
PegaSIPymt- Work- RemitBankPayReturnOfFund MT195, 199, Remitting bank — their
Return s1 payment to us
295, 299,
PegaSIPymt- Work- RemitBankPayReturnOfFund MT195, 199, Remitting bank — their
Return s2 payment to us
PegaSIPymt- RemitBankPayReturnOfFund MT195, 199, Remitting bank — their
s3 payment to us

PegaSIPymt- Work- RemitBankPayUnableEffectPyt MT195, 199, Remitting bank — their

UTEPay payment to us
295, 299,
PegaSIPymt- Work- RemitBankPayUnderpayment MT195, 199, Remitting bank — their
IncAmount payment to us
295, 299,
PegaSIPymt- Work- RemitBankPayWrongCoverIn1 MT195, 199, Remitting bank — their
IncCvr payment to us
295, 299,
PegaSIPymt- Work- RemitBankPayWrongCoverIn2 MT195, 199, Remitting bank — their
IncCvr payment to us
295, 299,
PegaSI-Work- ReplyToIncomingInquiry MT199, 299, Reply to incoming inquiry
PegaSI-Work- ReplyToIncomingInquiryAck MT199, 299, Reply incoming inquiry -
PegaSI-Work- RequestChargesFreeFormat MT191, 291 Request payment of charges

PegaSI-Work- Requestservicecharge MT191 Request service charge
Fed Service Correspondence Templates

Smart Investigate for Payments ships with the correspondence templates described in the table
below, which are used during Fed Service processing.

PegaSI-Work- AutoAck MT1090 English, Auto acknowledgement to
Inquirer work party
MT1590 English, MT1690
PegaSI-Work- Generalpurpose MT1001, MT1007, General purpose message
MT1033, MT1090,
MT1501, MT1507,
MT1590, MT1601,
PegaSI-Work- GeneralpurposewithticklerMT1001, MT1007, General purpose message with
s MT1033, MT1090, ticklers
MT1501, MT1507,
MT1590, MT1601,
PegaSI-Work- Adviceofcr MT1090 Advice of credit via 1090
PegaSI-Work- Adviceofcrind MT1090 Advice of credit via 1090
PegaSI-Work- Adviceofdr MT1090 Advice of debit via 1090
PegaSI-Work- Adviceofpay MT1090 Advice of payment via 1090
PegaSI-Work- Adviceofcr MT1690 Advice of credit via 1690
PegaSI-Work- Adviceofcrind MT1690 Advice of credit via 1690

PegaSI-Work- Adviceofdr MT1690 Advice of debit via 1690
PegaSI-Work- Adviceofpay MT1690 Advice of payment via 1690
Indemnity Correspondence Templates

below, which are used during indemnity processing.
Class Name Template Message Description Verification?

Type
PegaSI-Work- Confirmindemnityaction MT999 Confirm indemnity action Yes
PegaSI-Work- Confirmindemnityaction SWIFTNet Confirm indemnity action Yes

PegaSI-Work- Dcusccus202ind MT202 Indemnified—dr No
customer,
PegaSI-Work- Indemnity MT199 Indemnity via 199 Yes
PegaSI-Work- Indemnity SWIFTNet Indemnity Yes
PegaSI-Work- IndemnityNullAndVoid MT199 Indemnity null and void Yes
via
PegaSI-Work- IndemnityNullAndVoid SWIFTNet Indemnity null and void Yes
PegaSI-Work- IndemnityRecallOfFunds MT199 Recall of funds Yes
PegaSI-Work- IndemnityRecallOfFunds SWIFTNet Recall of funds Yes
PegaSI-Work- IndemnityRefundRequeste MT199 Refund requested on Yes
your
PegaSI-Work- IndemnityRefundRequeste SWIFTNet Refund requested Yes
PegaSI-Work- IndemnityReleased MT199 Indemnity released Yes

PegaSI-Work- IndemnityReleased SWIFTNet Indemnity released Yes
Compensation Correspondence Templates

below, which are used during compensation processing
Class Name Template Message Type Label Verification?

PegaSI- BackValueClaimDenied MT199 Back Value Compensation No
Compensatio Denied
PegaSI- BackValueDeclineToPay MT199 Decline to Pay Back No

Class Name Template Message Label Verification?
Type
PegaSI- Compensation Bvformcdbtdwash103 MT103 Cr Debit Original Value, No
Dr Wash, via
PegaSI- Compensation Bvformdcdtcwash202 MT202 B/V form, DR CDT orig No

value, CR comp rec'd
wash a/c, via
PegaSI- Compensation Bvformddbtcwash202 MT202 F/V form, DR DBT orig No
value, CR comp rec'd

PegaSI- Compensation Bvformdwashccdt202 MT202 B/V form, DR CR comp No
rec'd wash a/c new value,
CR CDT,
PegaSI- Compensation Bvformdwashcdbt103 MT103 Dr Wash, Cr Debit correct No

value, via 103
PegaSI- Compensation Bvformdwashcdbt202 MT202 B/V form, DR Wash, No
CR DebitParty orig value

PegaSI- Compensation Bvformdwashcdbt202ne MT202 B/V form, DR CR comp No
wval rec'd wash a/c new value,
CR CDT,
PegaSI- Compensation Claimamendbene MT199 Claim Amend Yes
beneficiary
PegaSI- Compensation Claimamendbene MT299 Claim Amend beneficiary Yes
Compensation
PegaSI- ClaimBackValue MT199 Claim Back Value Yes
PegaSI- ClaimBackValue MT299 Claim Back Value Yes
PegaSI- ClaimForwardValue MT199 Claim Forward Value Yes
PegaSI- Compensation ClaimForwardValue MT299 Claim Forward Value Yes

Compensation
PegaSI- ClaimUseOfFunds MT199 Claim Use of Funds Yes
PegaSI- ClaimUseOfFunds MT299 Claim Use of Funds Yes

Class Name Template Message Type Label Verification?
PegaSI- Compensation Dcomprcwash202 MT202 Dr Comp Received, Cr Comp No
Rec'd Wash,
PegaSI- Compensation Ddcuscwash202 MT202 Dr Customer, Cr No
Comp Paid Wash, via 202

PegaSI- Compensation Dfeecwash202 MT202 Dr Fee Account, Cr Wash No
Account, via
PegaSI- Compensation Drsvcwash202 MT202 Dr Reserve Account, No
Cr Wash Account, via 202

PegaSI- Dshortcwash202 MT202 Dr Short, Cr Comp No
PegaSI- Compensation Dusecwash202 MT202 Dr Use Account, Cr No
Wash Account, via 202

PegaSI- Compensation Dwashcccus202 MT202 Dr Comp Rec'd Wash, No
Cr Cust Account, via 202

PegaSI- Dwashccmpp103 MT103 Dr Wash, Cr Comp No
PegaSI- Dwashccmpp202 MT202 Dr Wash, Cr Comp No
PegaSI- Compensation Dwashcfee202 MT202 Dr Comp Rec'd Wash, Cr Fee No

Account, via
PegaSI- Compensation Dwashcover202 MT202 Dr Comp Rec'd Wash, Cr Over No

Account, via
PegaSI- Compensation Dwashcrsv202 MT202 Dr Comp Rec'd Wash, No
Cr Reserve Account, via 202

PegaSI- Compensation Dwashcuse202 MT202 Dr Comp Rec'd Wash, No
Cr Use Account, via 202

PegaSI- Compensation Fvformcdbtdwash1 MT103 Cr Debit orig value, Dr Wash, No
03 via 103
PegaSI- Fvformdwashccdt10 MT103 Dr Wash, Cr Credit No
3
PegaSI- Compensation Fvformdwashcdbt2 MT202 F/V form, DR Wash, CR No
02 DebitParty orig

Class Name Template Message Label Verification?
Type
PegaSI- Fvformdwashcdbt202ne MT202 F/V form, DR CR No
Compensatio wval comp rec'd wash a/c
n new value, CR CDT,
PegaSI- Requestdaamendbene MT199 Request amend Yes
PegaSI- Requestdaamendbene MT299 Request amend Yes

Compensatio beneficiary D/A
PegaSI- Requestdabackvalue MT199 Request back value Yes
PegaSI- Requestdabackvalue MT299 Request back value Yes
PegaSI- RequestdaForwardvalue MT199 Request Forward Yes
PegaSI- RequestdaForwardvalue MT299 Request Forward Yes
PegaSI- RequestdaUseOfFunds MT199 Request Use of Yes

Compensatio Funds D/A
PegaSI- RequestdauseOfFunds MT299 Request Use of Yes
Funds
Standard Correspondence Templates

The templates described in the table below are not used in Smart Investigate for Payments
workflows but are part of Process Commander and are available for your use. In addition, Smart
Investigate for Payments does not support Fax or PhoneText templates. If you decide to use any
of these templates, remember that they are samples, and that you will need to modify them to
meet your institution’s requirements.
Template Type Description

AcknowledgeSample Email, Fax, Mail, Sample template for internal
acknowledgement
Details Email, Fax, Mail Details of a work object.
ExternalAcknowledgeSample Email Sample template for external
acknowledgement
ExternalRequest Email Request for information about a work object
ExternalRequestBrief Email Assignment of a work object to an external

ExternalSample Email Sample template for correspondence with
Footer Email, Fax, Mail Signature for correspondence.

NewAssignment Email Notification of a new assignment on a

Template Type Description
NotifyReopen Email Notification of a resolved work object being
PromptSample Email, Fax, Mail, Sample template with prompt for user
input.
QuestionAboutItem Email, Fax, Mail, Request for more information about a work
ResolutionDetails Email, Fax, Mail Resolution details for a work object.

ResolutionSample Email, Fax, Mail, Sample template for work object resolution.
Structured Correspondence Templates

Smart Investigate for Payments ships with the structured correspondence templates described
in the table below.

Rule-PegaCommBank- Advicemailblank Email Advice e-mail — free Yes
Corr-Struct-Email format
Rule-PegaCommBank- Adviceofpay Email Advice of payment via e- Yes

Corr-Struct-Email mail
Rule-PegaCommBank- Ccemail Email CC e-mail Yes

Corr-Struct-Email
Rule-PegaCommBank- Emailfreeformat Email Free-format e-mail Yes

Corr-Struct-Email
Rule-PegaCommBank- Replytoincominginquiry Email Reply to incoming inquiry Yes

Corr-Struct-Email
Rule-PegaCommBank- Replytoincominginquiryac Email Reply to incoming inquiry Yes

Corr-Struct-Email k — acknowledgment
Rule-PegaCommBank- Unabletoapplyinquiry Email Unable to apply inquiry Yes

Corr-Struct-Email
Rule-PegaCommBank- Regardingcustpayment Email Receiving bank — Yes

Corr-Struct-Email outbound customer
payment
Rule-PegaCommBank- Custpaymentbenenonrece Email Receiving bank — Yes

Corr-Struct-Email ipt outbound payment —
beneficiary non receipt

Type
Rule-PegaCommBank- Requestforcharges Email Your payment — Yes
Corr-Struct-Email request for charges
Rule-PegaCommBank- Custpaymentlatepyt Email Receiving bank — Yes

Corr-Struct-Email outbound payment
— ensure
beneficiary receives
good value
Rule-PegaCommBank- Remitbankpayunableeffectpyt Email Remitting bank — Yes
Corr-Struct-Email their payment to us
— request for
further information
Rule-PegaCommBank- Generalpurpose Fax General purpose No

Corr-Struct-Fax
Rule-PegaCommBank- Generalpurposetick Fax General purpose No

Corr-Struct-Fax with ticklers
Rule-PegaCommBank- Freeformat Letter Free format No

Corr-Struct-Letter
Rule-PegaCommBank- Adviceblankltr Letter Advice blank letter No

Corr-Struct-Letter
Rule-PegaCommBank- Replytoincominginquiry Letter Reply to incoming No

Corr-Struct-Letter inquiry
Rule-PegaCommBank- Replytoincominginquiryack Letter Reply to incoming No

Corr-Struct-Letter inquiry —
acknowledgment
Rule-PegaCommBank- Unabletoapplyinquiry Letter Unable to apply No

Corr-Struct-Letter inquiry
Rule-PegaCommBank- Regardingcustpayment Letter Receiving bank — No

Corr-Struct-Letter outbound customer
payment
Rule-PegaCommBank- Custpaymentbenenonreceipt Letter Receiving bank — No

Corr-Struct-Letter outbound payment
— beneficiary non
receipt
Rule-PegaCommBank- Requestforcharges Letter Your payment — No
Corr-Struct-Letter request for charges

Type
Rule- Custpaymentlatepyt Letter Receiving bank — No
PegaCommBank- outbound payment —
Corr-Struct-Letter ensure beneficiary
receives good value
Rule- Remitbankpayunableeffec Letter Receiving bank — their No

PegaCommBank- tpyt payment to us —
Corr-Struct-Letter request for further
information
Sample Data
Smart Investigate for Payments is packaged and installed with test data. When entered as an
account number, ABA, or department code, the data is used to populate case party information
so that you can navigate through the business processes immediately after their installation and
train users without additional configuration.
Party Maintenance Data

You can search the database to find the detail data using any of the values listed in this table.
Party ID Branch Account Number ABA Number SWIFT BIC
LON100101 LON LON1434501892 021998810 PEGAUS33

LON100102 LON LON8554300629 — PEGAGB22
LON100103 LON LON1345433441 — PEGAJPJT
LON100104 LON LON5597987436 — PEGATHTB
LON100105 LON LON1955778102 —
LON100106 LON LON1088423341 — PEGAFRPP
LON100107 LON — — PEGAIE2D
LON100108 LON — — THAITHTB
LON100109 LON — — FRCHFRPP
LON100110 LON — — BANKTHTB
LON100111 LON — —
LON100112 LON — —
ZUR200101 ZUR ZUR2167007854 — PEGACHZZ
ZUR200102 ZUR ZUR2189003299 021998810 PEGAUS33
ZUR200103 ZUR ZUR4439003299 — PEGAUS33
ZUR200104 ZUR ZUR2190389992 — PEGAFRPP
ZUR200105 ZUR ZUR3090389992 — PEGAFRPP
ZUR200106 ZUR ZUR9078400232 — PEGAGB22
ZUR200107 ZUR ZUR8878400232 — PEGAGB22

Party ID Branch Account Number ABA Number SWIFT BIC
ZUR100108 ZUR ZUR0923000100 —
ZUR100109 ZUR ZUR0122989034 —
HEL300102 HEL HEL3768209122 — PEGAFIHH
HEL300103 HEL HEL3708456327 — PEGAGB22
HEL300104 HEL HEL3084563279 — PEGAGB22
HEL300105 HEL HEL5189003299 021998810 PEGAUS33
HEL300106 HEL HEL2489003299 — PEGAUS33
HEL300107 HEL HEL3768209144 —
HEL300108 HEL HEL3768209195 —
HEL300109 HEL HEL3768209101 — PEGACHZZ
STK300107 STK STK3909320126 — PEGASESS
STK300108 STK STK3028398552 — PEGAUS33
STK300109 STK STK3078358554 021998810 PEGAUS33
STK300110 STK STK3008400239 — PEGAGB22
STK300113 STK STK3098233646 — PEGAFRPP
MyCoSI-Party-InternalAccount
The data listed in the following table populates the Internal Account parties and defaults in the
debit and credit entries in accounting transactions.
Account Name Account Type Account Number Bank Number
AccountsPayable NOS ACP12345678 None

AccountsReceivable NOS ACR12345678 None
Fees NOS FEE12345678 None
InterestEarned NOS INE12345678 None
InterestPaid NOS INP12345678 None
Reserves NOS RSV12345678 None
ServiceFeesAccount NOS SFE12345678 None
SundryLosses NOS SUL12345678 None
SundryRecoveries NOS SUR12345678 None
SuspenseAssets NOS SUA12345678 None
SuspenseLiabilities NOS SUL12345678 None
WashAccount NOS WSH12345678 None

Appendix B: Sample Modeler
Workflows
This appendix shows the Smart Investigate flows for the following categories:
• Message Processing Workflows — Used during message processing to parse, format,

and process the messages.
• Accounting Workflows — Used when processing accounting transactions to repair,
verify, and create associated correspondence.
• Correspondence Workflows — Used when creating and sending correspondence.
• Case Processing Workflows — Used during case processing to check for duplicate cases
and to process transactions.
• Intent-Led Workflows — Used during customer interactions to evaluate what process
should be suggested to the CSR.
• Compensation Workflows — Used during claim processing to process the claims.
The tables starting on this page index the flow name, class, and page number in this
appendix with a diagram of the flow. You can also view these flows through Smart
Investigate for Payments using the class and flow names listed. For more detailed
information about Smart Investigate for Payments flows, use the Application Overview
section of the Manage Rules workspace and click Document.
See Flow Design Shapes for a brief description of the flow shapes.
Message Processing Flows

Flow Name Class Page
SWIFT ParseMessage PegaSI-MsgCase-Swift B-4
Fed Service ParseMessage PegaSI-MsgCase-FedSvc B-6
FreeFormatTextParse PegaSI-MsgCase B-6
StepByStep PegaSI-MsgCase B-7
Accounting Flows
AcctgRepair PegaCommBank-Work B-8
AcctgRepairDocument PegaCommBank-Work B-9
CreateAdjustment PegaCommBank-Work B-10
CreateTxnCorrespondence PegaCommBank-Work B-11
CreateAcctgCorrespondence PegaCommBank-Work B-12
FinStepVerifOneLevel PegaCommBank-Work B-13
FinStepVerifTwoLevels PegaCommBank-Work B-14
FinStepVerifThreeLevels PegaCommBank-Work B-15
Correspondence Flows
SendCorr PegaSI-Work- B-16
EnterCorrDetailsSF PegaCommBank-Corr- B-17
CorrCreateSBS PegaSI-Work- B-18
SwiftCorrCreate PegaCommBank-Work- B-19
FedSvcCorrCreate PegaCommBank-Work- B-20
AppCorrVerifySend PegaCommBank-Work- B-21
Case Processing Flows

StepByStep PegaSI-Work B-24
DuplicateSearch PegaSI-Work B-25
NewWork Pega-SI-Work-BulkEntry B-26
BCETranFlow PegaSI-Work-BulkEntry B-27
BCECollectTRNFromSpreadsheet PegaSI-Work-BulkEntry B-28
ProcessInboundIndemnity PegaSI-Work B-29
ProcessOutboundIndemnity PegaSI-Work B-30
Intent-led Flows
NewWork PegaSI-Work-BCNR B-31
BCNR PegaSI-Work-BCNR B-32
CoverNonReceipt PegaSI-Work-BCNR B-33
NewWork Pega-SI-Work-UTACr B-34
UltBeneUTA Pega-SI-Work-UTACr B-35
UTACover Pega-SI-Work-UTACr B-36
UTAStmtCR Pega-SI-Work-UTACr B-37
UTAPymtOrder Pega-SI-Work-UTACr B-38
NewWork Pega-SI-Work-Return B-39
NewWork PegaSI-Work-CorrBkChg B-40
Report Flows
SLAFlow PegaSI-Work-ScheduledReport B-41
VerifySendCorr PegaSI-Work-ScheduledReport B-42
Compensation Flows
Pega Smart Investigate for Payments Implementation Guide B-2

Flow Name Class Function
ClaimAmendBene PegaSI- Compensation Process Claim Amend Beneficiary
compensation; calls
ClaimAmendBeneSF PegaSI- Screen flow for processing Claim Amend
Beneficiary
ClaimBackValue PegaSI- Process Claim Back Value compensation;
calls
ClaimBackValueSF PegaSI- Screen flow for processing Claim Back
Value
ClaimForwardValue PegaSI- Process Claim Forward Value
compensation; calls
ClaimForwardValueSF PegaSI- Screen flow for processing Claim
Forward Value
ClaimUnjustEnrichment PegaSI- Compensation Process Claim Unjust Enrichment (use of
funds) compensation; calls
ClaimUnjustEnrichmentSF and
ClaimUnjustEnrichment PegaSI- Screen flow for processing Claim Unjust
SF Enrichment (use
CompensationAccountin PegaSI- Flow with assignment to enter
g compensation accounting
NewWork PegaSI- Called by all compensation cases OnAdd
InitialProcessing PegaSI- Called by compensation NewWork flow
PayAmendBene PegaSI- Process Pay Amend Beneficiary

compensation; calls
PayAmendBeneSF PegaSI- Screen flow for processing Pay Amend
Beneficiary
PayBackValue PegaSI- Process Pay Back Value compensation
PayBackValueSF PegaSI- Screen flow for processing Pay Back

Value compensation
PayForwardValue PegaSI- Process Pay Forward Value
compensation; calls
PayForwardValueSF PegaSI- Screen flow for processing Pay Forward
Value
PayUnjustEnrichment PegaSI- Compensation Process Pay Unjust Enrichment (use of
funds) compensation; calls
PayUnjustEnrichmentSF PegaSI- Screen flow for processing Pay Unjust
Enrichment (use of
ReceiveAmendBene PegaSI- Process Receive Amend Beneficiary
compensation; calls
ReceiveAmendBeneSF PegaSI- Screen flow for processing Receive
Amend Beneficiary
Compensation Flows

Flow Name Class Function
ReceiveBackValue PegaSI- Process Receive Back Value compensation
Compensation
ReceiveBackValueSF PegaSI- Screen flow for processing Receive Back
Value
ReceiveForwardValue PegaSI- Process Receive Forward Value
compensation; calls
ReceiveForwardValueSF PegaSI- Screen flow for processing Receive Forward
Value
ReceiveUnjustEnrichment PegaSI- Process Receive Unjust Enrichment (use of
funds)
ReceiveUnjustEnrichmentSF PegaSI- Screen flow for processing Receive Unjust
Enrichment
RequestAmendBene PegaSI- Process Request Amend Beneficiary
compensation; calls
RequestAmendBeneSF PegaSI- Screen flow for processing Request Amend
Compensation Beneficiary compensation
RequestBackValue PegaSI- Process Request Back Value compensation; calls
RequestBackValueSF PegaSI- Screen flow for processing Request Back Value
RequestForwardValue PegaSI- Process Request Forward Value compensation;

calls
RequestForwardValueSF PegaSI- Screen flow for processing Request Forward
Value
RequestUnjustEnrichment PegaSI- Process Request Unjust Enrichment (use of
Compensation funds) compensation; calls
RequestUnjustEnrichmentSF and
RequestUnjustEnrichmentSF PegaSI- Screen flow for processing Request Unjust
Enrichment
StepByStep PegaSI- Step by step processing for compensation cases
SWIFT ParseMessage
This flow parses incoming SWIFT messages into five blocks before the contents of the
message can be used for duplicate searching and automated queries to PegaRESEARCH
Manager.

Fed Service ParseMessage
This flow parses incoming Fed Service messages so that the contents of the message can
be used for duplicate searching and automated queries to PegaRESEARCH Manager.

FreeFormatTextParse
This flow interprets SWIFT MTn99 messages, which are free-format messages similar to e-
mails. Once interpreted, the system extracts the key data for processing.

Message Processing StepByStep
Messages that cannot be processed automatically are routed to a workbasket for operator
repair. Smart Investigate for Payments assigns this flow to these messages to enable
operators to perform tasks such as creating a new exception work object, dividing the
message, or attaching the message to an existing exception work object.

AcctgRepair
Supervisors who perform verification of accounting adjustments may return an adjustment to the
initiating operator to be fixed. This flow enables the adjustment to be returned to the initiating
operator who can then complete the fix, add new documents, or cancel the adjustment.

AcctgRepairDocument
This is a subflow in the main accounting adjustment verification flow (AcctgRepair, page 4)
and shows the repair of the document.

CreateAdjustment
This flow presents the operator with summary information for a final review at the
conclusion of the accounting adjustment. It also enables the operator to add additional
correspondence or to cancel the step.

CreateTxnCorrespondence
Transaction correspondence is driven by the payment types used in the adjustment. This
flow generates the correspondence documents.

CreateAcctgCorrespondence
This is a subflow in the main CreateAdjustment flow and shows the process for generating
an ad-hoc step-level document, for either Fed Service or SWIFT, from the accounting
summary screen.

FinStepVerifOneLevel
Accounting adjustments may require up to three levels of verification, depending on the
amount of the adjustment. This flow governs the first level verification.

FinStepVerifTwoLevels
amount of the adjustment. This flow governs the second level verification.

FinStepVerifThreeLevels
amount of the adjustment. This flow governs the third-level verification.

SendCorr
This flow shows the process of sending correspondence to another bank. If the user wants
to send copies of the correspondence, the flow CreateCCCorr is called.

EnterCorrDetailsSF
This screen flow is called from the SendCorr flow (4) to gather the information needed to
generate correspondence.

CorrCreateSBS
This flow is called from the SendCorr flow (4) to generate the correspondence record.

SwiftCorrCreate
This flow shows the process of creating an outbound SWIFT message to another bank.
FedSvcCorrCreate
This flow shows the process of creating an outbound Fed Service message to another bank.

AppCorrVerifySend
This flow governs what happens once an operator (or automated process) is ready to
submit a Fed Service or SWIFT message. Once the message is submitted, it may require
verification, repair, or ticklers.

AppCorrTicklerVerifySend
A tickler is an automated follow-up message to a previously sent message. This flow
controls the sending of the messages, including whether the message requires verification.

AppCorrRepair
While reviewing a correspondence verification assignment, a supervisor can elect to return
the assignment to the initiating operator for repair. This flow controls what happens to the
repair assignment.

If the user encounters any exception at Repair correspondence stage, supervisor will be
able to abandon correspondence, resend correspondence or transfer the assignment.
Case Processing StepByStep

This flow is the primary flow on an exception work object. This flow initiates the sending of
auto acknowledgements and provides the operator with the ability to initiate functions
such as creating a message, transferring a case, or creating an adjustment.

DuplicateSearch
Following case entry (and at other times under the control of another flow), a case goes
through a duplicate checking process to ensure that there is not another case in the
system concerning the same transaction.

Bulk Entry NewWork
This flow starts the Bulk Entry process. It either calls the Transaction flow (manual entry) or
collects the transaction information from a spreadsheet through a SOAP call. Once the data
is received, Payment objects are created and processed in the system.

BCETranFlow
This is the portion of the bulk case entry transaction flow where transaction information is
entered from an excel spreadsheet and displayed. This flow is called from the Bulk Case
Entry NewWork flow (page 4).

BCECollectTRNFromSpreadsheet
This flow is called from the Bulk Entry New Work flow (page 4 to upload an Excel
spreadsheet containing the transaction information needed to create the work objects.
ProcessInboundIndemnity

This flow processes inbound indemnities as a step-by-step processing action. The user can
honor the indemnity, declare it null and void, or cancel it
ProcessOutboundIndemnity
This flow processes outbound payment or nostro indemnities as a step-by-step processing
action.

BCNR NewWork
This is the beginning of the Beneficiary Claims Non Receipt intent-led flow.

BCNR
This flow is called by NewWork (4) when the Beneficiary claims non receipt.

CoverNonReceipt
This flow is called by the NewWork flow (4) when the receiving bank claims non receipt of
this cover.
UTACr NewWork
This is the start of the intent-led flow for Unable to Apply Credit.

UltBeneUTA
This flow is called by the UTACr NewWork flow (4) when the ultimate beneficiary cannot
apply the funds.

UTACover
This flow is called by the UTACr NewWork flow (4) when the receiving bank is unable to
apply the cover payment.
UTAStmtCR
This flow is called by the UTACr NewWork flow (4) when the receiving bank has received a
credit on their statement that they cannot apply.

UTEPymtOrder
This flow is called by the UTACr NewWork flow (4) when the receiving bank cannot effect the
payment order they have received.

Return NewWork
This is the intent-led flow for return of funds.

Corresponding Bank Charges (MT191) New Work
This intent-led flow automates the receipt and processing of SWIFT MT191 messages. It
uses both the Send Correspondence and AutoAccounting background flows.

SLAFlow
This flow sets the initial SLA values, schedules the report to run, and routes any exceptions.
VerifySendCorr
This flow checks to make sure the verification is necessary and then sends the
correspondence.

Compensation NewWork
This is the start of the compensation case flows. This flow calls the InitialProcessing flow
and then starts the StepbyStep flow.

InitialProcessing
This flow is called by compensation NewWork flow (page 4). It calls the EntryProcessing
activity and initiates background processing for those cases where PutOnMyWorklist is not
set to Yes.

PayBackValue
This flow processes Pay Back Value compensation. It calls the PayBackValueSF flow (page
4).

PayBackValueSF
This is the screen flow for processing Pay Back Value compensation (see page 4).

ReceiveBackValue
This flow processes Receive Back Value compensation cases. It calls the
ReceiveBackValueSF flow (page 4).

ReceiveBackValueSF
This is the screen flow for processing Receive Back Value compensation.

StepByStep
This is the step by step processing flow for compensation cases. Step by Step assignment
has the flow actions Send_Messages, ResolveCase, and StartAdjustment, and the local
actions StartCompAccounting and Transfer.

Appendix C: Text Parsing Rules
This appendix lists the preconfigured text parsing and normalization rules. For information
on how to set up free-text parsing, see Chapter 6, Integrating Smart Investigate.
Parsing Dates
The rules defined in this section apply to Transaction Date and Value Date.
Locate Step
The parser recognizes dates in the following formats:
MMM = JAN, FEB, …, DEC; MM or M is a numeric value between 1 and 12.
D M YY DD.M.YY D-MMM-YY M-D-YY

D MM YY DD.M.YYYY DMMMYYYY M-D-YYYY
D MMM YY DD.MM.YY D-MMM-YYYY MM.D
D MMM YYYY DD.MM.YYYY D-MM-YY MM.D.YY
D.M DD.MMM.YY D-MM-YYYY MM.D.YYYY
D.M.YY DD.MMM.YYYY D-M-YY MM.DD.YY
D.M.YYYY DD/M D-M-YYYY MM.DD.YYYY
D.MM DD/M/YY M.D MM/D
D.MM.YY DD/M/YYYY M.D.YY MM/D/YY
D.MM.YYYY DD/MM/YY M.D.YYYY MM/D/YYYY
D.MMM.YY DD/MM/YYYY M.DD MM/DD/YY
D.MMM.YYYY DD-M M.DD.YY MM/DD/YYYY
D/M DDMMMYY M.DD.YYYY MM-D
D/M/YY DD-MMM-YY M/D MM-DD-YY
D/M/YYYY DDMMMYYYY M/D/YY MM-DD-YYYY
D/MM DD-MMM-YYYY M/D/YYYY MM-D-YY
D/MM/YY DD-MM-YY M/DD MM-D-YYYY
D/MM/YYYY DD-MM-YYYY M/DD/YY MMMDD YY
DD M YY DD-M-YY M/DD/YYYY MMMDD YYYY
DD MM YY DD-M-YYYY M-D YY.MM.DD
DD MMM YY D-M M-DD YYMMDD
DD MMM YYYY D-MM M-DD-YY YYYY.MM.DD
DD.M DMMMYY M-DD-YYYY YYYYMMDD
Where one of the following words optionally appears in the preceding n characters (a
configurable value), the located date is processed as a transaction date:
DT SENT 100 205

DATED ON 103 INSTRUCTION
Pega Smart Investigate for Payments Implementation Guide C-1

DATE OF 202 PAYMENT
DTD DATD 200 P/O
DD MT 201 FOR
POSTED ORDER 203 P.O.
However, if one of the following optional words appears in the preceding n characters, the
located date is processed as a value date:
• VALUE
• VAL
• VALUED
• V/D
• V.D.
Manipulate/Translate Step
If a date is found, it is converted to the standard Java DATE format (not DATETIME).
Test/Validate Step
The following test conditions are possible as part of a When rule:
Is {Located Date} < $TODAY Is {Located Date} = $TODAY

Is {Located Date} <= $TODAY Is {Located Date} > $TODAY
Is {Located Date} >= $TODAY Is {Located Date} <
Is {Located Date} = {.DateProperty} Is {Located Date} <=
Is {Located Date} > {.DateProperty} Is {Located Date} >=
Map/Output Step
If the Test/Validate step returns TRUE, or no test/validate step is used and data has been
successfully located, the output is saved as a property.
Parsing Amounts
The rules defined in this section apply to Transaction Amount.
Locate Step
The parser recognizes amounts in the following formats:
• CCC.999999999999999,9999
• CCC999999999999999,
• 9999 999999999999999,9999/CCC
• CCC. 999999999999999,9999
• 999999999999999,9999 CCC
Where:
• CCC is a valid ISO currency code such as USD, GBP, or EUR

• The decimal point is a decimal comma or a period separating the whole number from
the fraction
• The whole number string is 15 digits maximum, including punctuation if present; if
present, the 000 separator can be a period or a comma
• The decimal fraction is four digits maximum and if zero can be represented as follows:
999,0 999,00 999,000

999,0000 999, 999,-
999 999. 999.0
999.00 999.000 999.0000
999.-
• If a 000 separator is present, and a separator for the whole numbers and fractions is
also present, they will be different; for example, 1,000.00 or 1.000,00
Sample Amounts
Each of the following examples is recognized as one million Japanese yen:
• JPY1000000, JPY1.000.000, JPY1.000.000 JPY 1,000,000 JPY1000000,- JPY 1000000.-

1,000,000/JPY
Each of the following examples is recognized as fifteen hundred Australian dollars:
• AUD1,500.00 AUD 1,500 AUD1500 AUD1.500, AUD1.500,00 AUD1.500,- AUD1,500.-

AUD 1500.00 1500.00/AUD
One of the following words may optionally appear in the preceding n characters:
• PAY AMOUNT FOR PAYMENT OF
If an amount is found, it is converted to the Pega 8 standard Amount With Currency
format.
Test/Validate Step
The following test conditions are possible as part of a When rule:
Is {Located Amount} < {.AmountProperty} Is

{Located Amount} = {.AmountProperty} Is {Located
Amount} <= {.AmountProperty} Is {Located
Amount} > {.AmountProperty} Is {Located Amount}
>= {.AmountProperty} Is {Located Amount} <
“LiteralAmount”
Is {Located Amount} =
“LiteralAmount” Is
{Located Amount} <=
{Located Amount} >
{Located Amount} >=
“LiteralAmount”
Is currency of {Located Amount} = “XXX” or “XXX” or “XXX” (where XXX = ISO currency)
Map/Output Step
Parsing Receiver’s Inquiry References

The Smart Investigate for Payments case reference follows a known structure.
Locate Step
The parser recognizes inquiry references in the following formats:
XX-YYMMDD-999999 XXXYYMMDD-999999 X-YYMMDD-999999
where
• XX-, X- or XXX is a known string (the default in PegaSI_Sample is “PEG”)

• YYMMDD is a valid SWIFT format date
• 999999 is a 6-digit sequence number
The locate process allows for the fact that a reference may be misquoted, resulting in the “-
” sometimes being a period or “/” or space. Also, the sequence number may contain “O”
instead of zeros or may not contain all the lead zeros.
The output of the TRANSLATE step ensures that the value is a correctly formatted case ID.
Validate Step
The located value is tested to see if it is present in the Process Commander pc_work table.
This is an indication that the value is a valid case ID.
Map/Output Step
Parsing Receiver’s Transaction References

The receiver’s transaction reference is usually in a known format. It may contain embedded
dates, often in a Julian date format, with a few characters that represent a product code
and a sequence number of some kind. The PegaSI_Sample RuleSet provides a sample
Transaction Reference pattern that can be cloned and modified as needed.
Locate Step
The parser recognizes inquiry references in the format BBBYYJJJPP-99999, where:
• BBB is a known branch number, such as LON, PAR, NYK, FFT, COP, HEL, or SYD
• YY is a year from 1995 onwards
• JJJ is a Julian date from 001 to 366
• PP is a known product code, such as AA, BB, CC, DD, EE, FF, GG
• - is a literal dash
The parser checks for cases where the sequence number contains “O” rather than zeros,
where the sequence number is missing lead zeros, and where the “-” is missing or replaced
by a “/” or “.” or “_”.
The output of the TRANSLATE step ensures that the value is a correctly formatted case ID.
Validate Step
May reference a WHEN block.
Map/Output Step

Parsing Sender’s Transaction References
The sender’s transaction reference may appear in field 21 of the SWIFT message or may
appear in the body of the message preceded by a string such as “OUR REF:”. The reference
format is unknown and unpredictable and so cannot be located based upon a pattern.
Instead, the preceding string (such as OUR REF:) is located and the next token extracted
and passed to the manipulation and validation steps.
Locate
The parser recognizes the following strings or phrases that may precede a Sender’s
Transaction reference:
OUR REF OUR REF.

OUR REF: OUR TRN
OUR TRN. OUR TRN:
OUR REFERENCE OUR REFERENCE.
OUR REFERENCE: OUR PAYMENT TRN
OUR PAYMENT TRN. OUR PAYMENT TRN:
OUR PAYMENT REF OUR PAYMENT REF.
OUR PAYMENT REF: OUR PAYMENT REFERENCE
OUR PAYMENT REFERENCE. OUR PAYMENT REFERENCE:
OUR MT103 REF OUR MT103 REF.
OUR MT103 REF: OUR MT202 REF
OUR MT202 REF. OUR MT202 REF:
OUR MT103 TRN OUR MT103 TRN.
OUR MT103 TRN: OUR MT202 TRN
OUR MT202 TRN. OUR MT202 TRN:
OUR MT103 REFERENCE OUR MT103 REFERENCE.
OUR MT103 REFERENCE: OUR MT202 REFERENCE
OUR MT202 REFERENCE. OUR MT202 REFERENCE:
OUR P/O TRN OUR P/O TRN.
OUR P/O TRN: OUR P/O REF
OUR P/O REF. OUR P/O REF:
OUR P/O REFERENCE OUR P/O REFERENCE.
OUR P/O REFERENCE: OUR SWIFT P/O TRN
OUR SWIFT P/O TRN. OUR SWIFT P/O TRN:
OUR SWIFT P/O REF OUR SWIFT P/O REF.
OUR SWIFT P/O REF: OUR SWIFT P/O REFERENCE
OUR SWIFT P/O REFERENCE. OUR SWIFT P/O REFERENCE:
OUR SWIFT MT103 REF OUR SWIFT MT103 REF.
OUR SWIFT MT103 REF: OUR SWIFT MT202 REF
OUR SWIFT MT202 REF. OUR SWIFT MT202 REF:
OUR SWIFT MT103 TRN OUR SWIFT MT103 TRN.
OUR SWIFT MT103 TRN: OUR SWIFT MT202 TRN
OUR SWIFT MT202 TRN. OUR SWIFT MT202 TRN:
OUR SWIFT MT103 REFERENCE OUR SWIFT MT103 REFERENCE.
OUR SWIFT MT103 REFERENCE: OUR SWIFT MT202 REFERENCE

OUR SWIFT MT202 REFERENCE. OUR SWIFT MT202 REFERENCE:
If found, the parser extracts the string of characters that follows, up to the next white
space.
May select from any of the translate options.
Validate Step
Map/Output Step
Parsing IMADs
Input Message Accountability Data (IMAD) is a unique number assigned to track each
Fedwire transaction sent by a financial institution. The IMAD number is in a known format
containing an embedded date, with characters that represent a routing code and then a
sequence number.
The PegaSI_Sample RuleSet provides a sample Transaction Reference pattern,

FindFedIMAD, that can be cloned and modified as needed.
Locate Step
The parser recognizes inquiry references in the format
ssssssssYYYYMMDDXXXXXXXX999999, where:
• ssssssss is one of the strings IMAD, SEQ, SEQUENCE, FEDWIRE, FED WIRE, WIRE, or FED
• YYYYMMDD is a date (which is validated)
• XXXXXXXX is an 8-character alphanumeric string
The parser accepts cases where the string ssssssss is followed by a space, period, slash,
colon, linefeed, or carriage return.

The output of the TRANSLATE step ensures that the value is a correctly formatted 6-digit
IMAD.
Validate Step
Map/Output Step
Parsing CHIPS Sequence Numbers

The Clearing House Interbank Payments System (CHIPS) is an electronic payments system
that transfers funds and settles transactions in U.S. dollars. The CHIPS sequence number is
in a known format, with characters that represent a routing code and then a sequence
number.
The PegaSI_SampleRuleSet provides a sample Transaction Reference pattern,

FindCHIPSSequenceNum, that can be cloned and modified as needed.
Locate Step
The parser recognizes inquiry references in the format ssssssssssssss9999999, where:
• ssssssssssssss is one of the strings SSN, CHIPS SEQ, CHIPS SEQUENCE, or CHIPS SSN
• 9999999 is a 4- to 7-digit sequence number
The parser accepts cases where the string ssssssss is followed by a space, period, slash,
colon, linefeed, or carriage return.
The output of the TRANSLATE step ensures that the value is a correctly formatted 4- to 7-
digit CHIPS sequence number.
Validate Step

Map/Output Step
Parsing Work Types

Smart Investigate for Payments supports the following work types, though parsing is not
done for all of them:
• Amend Beneficiary
• Beneficiary Claims Non Receipt
• Cancellation Request
• Correspondent Bank Charges
• Duplicate Payment
• Incorrect Amount
• Incorrect Bank Paid
• Incorrect Charges
• Incorrect Credit Account
• Incorrect Cover
• Incorrect Date
• Incorrect Debit Account
• Miscellaneous
• Nostro Ledger Credit
• Nostro Ledger Debit
• Nostro Statement Credit
• Nostro Statement Debit
• Nostro Value Difference
• Quick Kill
• Return of Funds
• Unable to Apply Credit
• Unable to Apply Debit
• Unable to Effect Payment

Locate Work Type = Amend Beneficiary
The parser locates the following words or phrases in the order the words appear (left to
right):
“AMEND THE BENEFICIARY” “AMEND” “NAME” “BENEFICIARY”

“AMEND” “INSTRUCTIONS” “PAY” “AMEND” “BENEFICIARY” “ACCOUNT”
“AMEND” “BENEFICIARY” “ACCT” “AMEND” “BENEFICIARY” “A/C”
“AMEND” “BENEFICIARY” “NAME” “AMEND” “BENEFICIARY”
“AMEND” “BNF” “ACCOUNT” “AMEND” “BNF” “ACCT”
“AMEND” “BNF” “A/C” “AMEND” “BNF” “NAME”
“AMEND” “BNF” “AMEND” “BENE” “ACCOUNT”
“AMEND” “BENE” “ACCT” “AMEND” “BENE” “A/C”
“AMEND” “BENE” “NAME” “AMEND” “BENE”
“CORRECT BENEFICIARY SHOULD” “AMEND” “FIELD 59”
“AMEND” “FIELD59” “AMEND” “59”
“BENEFICIARY” “SHOULD” “AMEND” “PAYMENT” “F/O”
“AMEND” “PAYMENT” “FAV” “AMEND” “PAYMENT” “FAVOUR”
“AMEND” “PAYMENT” “AMEND” “P/O”
“AMEND” “FIELD 58” “AMEND” “FIELD58”
“AMEND” “58” “AMEND” “ACCOUNT”
“AMEND” “ACCT” “AMEND” “A/C”
“AMEND” “103” “AMEND” “202”
“:/5/” “:/8/”
“:/9/” “BENEFICIARY” “SHOULD” “READ”
“BENE” “SHOULD” “READ” “BNF” “SHOULD” “READ”
“A/C” “SHOULD” “READ” “ACCT” “SHOULD” “READ”
“ACCOUNT” “SHOULD” “READ”
Translate/Manipulate
If found, the parser maps “ABN” to the WorkType property.
Locate Work Type = Beneficiary Claims Non Receipt

right):
“BENEFICIARY” “NON” “RECEIPT” “BENE” “NON” “RECEIPT”

“BEN “NON” “RECEIPT” “BNF” “NON” “RECEIPT”
“BENEF” “NON” “RECEIPT” “BENE” “NOT” “RECEIVED”
“BENEFICIARY” “NOT” “RECEIVED” “BEN” “NOT” “RECEIVED”
“BENEF” “NOT” “RECEIVED” “/3/”
“BENEFICIARY” “NOT” “CREDIT” “BENEFICIARY” “NOT” “CREDITED”
“BENE” “NOT” “CREDIT” “BENE” “NOT” “CREDITED”
“BNF” “NOT” “CREDIT” “BNF” “NOT” “CREDITED”

“BENEF” “NOT” “CREDIT” “BENEF” “NOT” “CREDITED”
“COUNTERPARTY” “NON” “RECEIPT” “COUNTERPARTY” “NOT” “RECEIVED”
“COUNTERPARTY” “NOT” “CREDIT” “ACCOUNT” “NOT” “CREDIT”
“A/C” “NOT” “CREDIT” “ACCT” “NOT” “CREDIT”
“WHEN” “BNF” “ACCOUNT” “CREDIT” “WHEN” “BEN” “ACCOUNT” “CREDIT”
“WHEN” “BENE” “ACCOUNT” “CREDIT” “WHEN” “BENEF” “ACCOUNT” “CREDIT”
“WHEN” “BENEFICIARY” “ACCOUNT” “CREDIT” “WHEN” “BNF” “ACCT” “CREDIT”
“WHEN” “BEN” “ACCT” “CREDIT” “WHEN” “BENE” “ACCT” “CREDIT”
“WHEN” “BENEF” “ACCT” “CREDIT” “WHEN” “BENEFICIARY” “ACCT” “CREDIT”
“WHEN” “BNF” “A/C” “CREDIT” “WHEN” “BEN” “A/C” “CREDIT”
“WHEN” “BENE” “A/C” “CREDIT” “WHEN” “BENEF” “A/C” “CREDIT”
“WHEN” “BENEFICIARY” “A/C” “CREDIT” “NOT” “CREDIT”
“FUNDS” “NOT CREDITED” “HAVEN’T” “RECEIVED” “FUNDS”
“BNF” “NEVER” “CREDIT” “BEN” “NEVER” “CREDIT”
“BENE” “NEVER” “CREDIT” “BENEF” “NEVER” “CREDIT”
“BENEFICIARY” “NEVER” “CREDIT” “NON” “RECEIPT”
“NOT” “RECEIVED” “ACCOUNT” “NOT” “RECEIVED” “ACCT”
“NOT” “RECEIVED” “A/C” “NOT” “RECEIVED” “FUNDS”
“AWAIT” “FUNDS” “NON” “RECEIPT” “FUNDS”
“NONRECEIPT” “FUNDS” “N/R” “FUNDS”
“IF” “RECEIVED” “FUNDS”
If found, the parser maps “BNR” to the WorkType property.
Test/Validate
Map Output
successfully located, the translated output is saved in the WorkType property.
Locate Work Type = Cancellation Request

right):
“PLEASE CANCEL OUR” “PLEASE CANCEL THIS”

“PLEASE RETURN” “MADE IN ERROR”
“PAID IN ERROR” “SENT IN ERROR”
“EXECUTED IN ERROR” “MESSAGE” “IN ERROR”
“P/O” “IN ERROR” “PAYMENT” “IN ERROR”
“103” “IN ERROR” “202” “IN ERROR”

“MESSAGE” “BY ERROR” “P/O” “BY ERROR”
“PAYMENT” “BY ERROR” “103” “BY ERROR”
“202” “BY ERROR” “REJECT”
“RECALL” “DISREGARD” “PAYMENT”
“DISREGARD” “P/O” “DISREGARD” “103”
“DISREGARD” “202” “STOP” “PAYMENT”
“RETRIEVE” “IGNORE” “ORDER”
“IGNORE” “PAYMENT” “IGNORE” “103”
“IGNORE” “202” “IGNORE” “MESSAGE”
{2:O192 {2:O292
{2:I192 {2:I292
“FUNDS BE RETURNED” “FUNDS TO BE RETURNED”
“NOT INTENDED FOR YOU” “PAID” “IN ERROR”
“DEBIT YOUR ACCOUNT” “CANCELLATION” “DEBIT YOUR ACCOUNT” “REFUND”
“DEBIT YOUR ACCOUNT” “REVERSAL “DEBIT YOUR ACCT” “CANCELLATION”
“DEBIT YOUR ACCT” “REFUND” “DEBIT YOUR ACCT” “REVERSAL”
“DEBIT YOUR A/C” “CANCELLATION” “DEBIT YOUR A/C” “REFUND”
“DEBIT YOUR A/C” “REVERSAL” “DEBIT YOU’RE A/C” “CANCELLATION”
“DEBIT YOU’RE A/C” “REFUND” “DEBIT YOU’RE A/C” “REVERSAL”
“OUR” “RETURN” “FUNDS” “RETURNING” “FUNDS”
“RECREDITED” “REQUEST YOU TO CANCEL”
“PLEASE RETURN OUR”
If found, the parser maps “CNL” to the WorkType property.
Locate Work Type = Correspondent Bank Charges

right):
“{2:O190”
“{2:I190”
“{2:O191”
“{2:I191”
If found, the parser maps “CBC” to the WorkType property.
Locate Work Type = Duplicate Payment

right):

“:/7/”
“:/22/” “DUPLICATE” “DOUBLE” “TWICE”
If found, the parser maps “DUP” to the WorkType property.
Locate Work Type = Incorrect Amount

right):
“CORRECT AMOUNT” “AMOUNT SHOULD”

“AMOUNT” “PAYMENT” “SHOULD” “INCORRECT AMOUNT”
“INCORRECT CURRENCY” “UNDERPAID”
“UNDER PAID” “OVER PAID”
“OVERPAID” “OVERPAYMENT’
“UNDERPAYMENT’ “OVER PAYMENT’
“UNDER PAYMENT’ “REMITTED” “INSTEAD OF”
“REMITTED” “SHOULD BE” “SHOULD” “ONLY”
“AMEND” “AMOUNT” “WRONG AMOUNT”
“WRONG CURRENCY” “PAYMENT FOR” “INSTEAD OF”
“EXCESS” “AMEND” “32”
“AMEND” “32” “AMEND” “33”
“CORRECT” “AMOUNT” “EXPECTED” “ONLY”
“ONLY” “EXPECTED” “AMOUNT” “NOW READS”
“DIFFERENCE” “CHANGE” “AMOUNT”
“AMEND” “CURRENCY” “READ” “32”
“READ” “33” “CONSIDER” “32”
“CONSIDER” “33” “RECEIVED” “ONLY”
“ONLY” “RECEIVED” “32” “TO READ”
“33” “TO READ” “:/45/”
If found, the parser maps “IAM” to the WorkType property.
Locate Work Type = Incorrect Bank Paid

The parser locates the following words or phrases, in the order the words appear (left to
right):
“NAME OF BANK” “AMEND” “57”

“AMEND” “BNF BANK” “AMEND” “BENEFICIARY BANK”
“CORRECT BEN” “BANK NAME” “CORRECT” “FIELD 57”
“CORRECT” “FIELD57” “CORRECT” “NAME” “BANK”

“CORRECT” “FIELD 56” “CORRECT” “FIELD56”
“:/46/” “BENEFICIARY” “BANK” “SHOULD READ”
If found, the parser maps “IBP” to the WorkType property.
Locate Work Type = Incorrect Charges

right):
If found, the parser maps “CHG” to the WorkType property.
Locate Work Type = Incorrect Credit Account

right):
“:/44/” “CREDIT” “WRONG A/C”

“CREDIT” “WRONG ACCT” “CREDIT” “WRONG ACCOUNT”
“CREDIT” “INCORRECT A/C” “CREDIT” “INCORRECT ACCT”
“CREDIT” “INCORRECT ACCOUNT” “WRONG A/C” “CREDIT”
“WRONG ACCT” “CREDIT” “WRONG ACCOUNT” “CREDIT”
“INCORRECT A/C” “CREDIT” “INCORRECT ACCT” “CREDIT”
“INCORRECT ACCOUNT” “CREDIT” “ACCOUNT” “WRONG” “CORRECT”
If found, the parser maps “ICA” to the WorkType property.
Locate Work Type = Incorrect Cover

The parser locates the following words or phrases, in the order the words appear:
“COVER” “AMEND” “53”

“AMEND” “54”
If found, the parser maps “CVR” to the WorkType property.
Locate Work Type = Incorrect Date

right):
“CORRECT VAL” “CORRECT VALUE”

“CORRECT DATE” “ADJUST” “VAL”
“ADJUST” “VALUE” “ADJUST” “DATE”
“APPLY VALUE” “APPLY VAL”
“EXPECTED” “VALUE” “EXPECTED” “VAL”
“B/V” “BACK VALUE”
“BACKVALUE” “BACKVALUATION”
“VALUE” “S/B” “VALUE” “SHOULD”
“ARRANGE” “GOOD VALUE” “AMEND” “VALUE”
“READ” “VALUE DATE AS” “VALUE” “TO READ”
“SHOULD BE VALUE” “SHOULD BE FOR VALUE”
“SHOULD BE VAL” “SHOULD BE FOR VAL”
“S/B VALUE” “S/B FOR VALUE”
“S/B VAL” “S/B FOR VAL”
“COSTS” “ENSURE VALUE”
“APPLY GOOD VALUE” “WRONG VALUE”
“VALUE DATE” “WRONG” “WRONG” “VALUE DATE”
“WRONG” “VALUE” “ONLY VALUE”
“ONLY WITH VALUE” “VALUE” “INSTEAD OF”
“VALUE” “I/O” “CHANGE” “VALUE”
“FORWARD VALUE” “LATE”
“EARLY” “:/12/”
“:/40/” “:/41/”
“:/42/”
If found, the parser maps “IDT” to the WorkType property.
Locate Work Type = Incorrect Debit Account

The parser locates the following words or phrases, in the order the words appear (left to
right):
“:/47/” “DEBIT” “WRONG A/C”

“DEBIT” “WRONG ACCT” “DEBIT” “WRONG ACCOUNT”
“DEBIT” “INCORRECT A/C” “DEBIT” “INCORRECT ACCT”
“DEBIT” “INCORRECT ACCOUNT” “WRONG A/C” “DEBIT”
“WRONG ACCT” “DEBIT” “WRONG ACCOUNT” “DEBIT”
“INCORRECT A/C” “DEBIT” “INCORRECT ACCT” “DEBIT”
“INCORRECT ACCOUNT” “DEBIT”
If found, the parser maps “IDA” to the WorkType property.
Locate Work Type = Return of Funds

right):
“RETURNED FUNDS” “RTND FUNDS”

“RETURNED TO YOUR ACCOUNT” “FUNDS RTND”
“FUNDS RETURNED” “YOUR” “PAYMENT” “NULL AND VOID”
“CANCELLED” “YOUR PAYMENT” “CANCELLED” “YOUR INSTRUCTIONS”
“WE HAVE” “ CANCELLED YOUR” “RETURNED THE FUNDS”
“WE ARE CREDITING” “IN REVERSAL” “CONSIDER YR” “NULL AND VOID”
“CONSIDER YOUR” “NULL AND VOID” “CONSIDER YR” “CANCELLED”
“CONSIDER YOUR” “CANCELLED” “CONSIDERED YOUR” “NULL AND VOID”
“CONSIDERED YR” “NULL AND VOID” “DEBIT OUR” “RETURN” “FUNDS”
“WE CREDIT” “REVERSAL” “PAYMENT” “WE CREDIT” “REVERSAL” “FUNDS”
“WE RETURN” “MT” “CREDIT YOUR ACCOUNT” “REVERSAL”
“FUNDS” “NOT INTENDED FOR OUR” “RETURN”
If found, the parser maps “RTN” to the WorkType property.
Locate Work Type = Unable to Apply Credit

right):
“UNABLE” “APPLY” “FUNDS” “UNABLE” “APPLY” “CREDIT”

“UNABLE” “APPLY” “AMOUNT” “UNABLE” “APPLY” “PAYMENT”
“UNABLE” “APPLY” “PYT” “UNABLE” “APPLY” “TRANSACTION”
“UNABLE” “APPLY” “FURTHER DETAILS” “FUNDS”
“FURTHER DETAILS” “CREDIT” “FURTHER DETAILS” “AMOUNT”
“FURTHER DETAILS” “PAYMENT” “FURTHER DETAILS” “PYT”
“FURTHER DETAILS” “TRANSACTION” “FURTHER DETAILS”
“MORE DETAILS” “FUNDS” “MORE DETAILS” “CREDIT”
“MORE DETAILS” “AMOUNT” “MORE DETAILS” “PAYMENT”
“MORE DETAILS” “PYT” “MORE DETAILS” “TRANSACTION”
“MORE DETAILS” “BENEFICIARY” “APPLY” “CREDIT”
“BENEFICIARY” “APPLY” “FUNDS” “BENEFICIARY” “APPLY” “AMOUNT”
“BENEFICIARY” “APPLY” “PAYMENT” “BENEFICIARY” “APPLY” “PYT”
“BENEFICIARY” “APPLY” “TRANSACTION” “NAME” “APPLY” “FUNDS”
“CANNOT” “APPLY” “FUNDS” “CANNOT” “APPLY” “CREDIT”
“CANNOT” “APPLY” “AMOUNT” “CANNOT” “APPLY” “PAYMENT”
“CANNOT” “APPLY” “PYT” “CANNOT” “APPLY” “TRANSACTION”
“CANNOT” “APPLY” “CANNOT IDENTIFY THE CREDIT”
“CANNOT IDENTIFY CREDIT” “CAN NOT IDENTIFY THE CREDIT”
“CAN NOT IDENTIFY CREDIT” “NOT” “ABLE” “APPLY” “FUNDS”
“NOT” “ABLE” “APPLY” “CREDIT” “NOT” “ABLE” “APPLY” “AMOUNT”
“NOT” “ABLE” “APPLY” “PAYMENT” “NOT” “ABLE” “APPLY” “PYT”
“NOT” “ABLE” “APPLY” “TRANSACTION” “NOT” “ABLE” “APPLY”
“UNABLE” “IDENTIFY” “FUNDS” “UNABLE” “IDENTIFY” “CREDIT”
“UNABLE” “IDENTIFY” “AMOUNT” “UNABLE” “IDENTIFY” “PAYMENT”
“UNABLE” “IDENTIFY” “PYT” “UNABLE” “IDENTIFY” “TRANSACTION”

“UNABLE” “IDENTIFY” :/14/
:/19/ :/17/
:/4/ “NAME” “ORDER” “CUSTOMER”
“ORDER” “CUSTOMER” “NAME” “NAME” “REMITTER”
“REMITTER” “NAME” “ADVISE” “ORDER” “CUSTOMER”
“KNOW” “ORDER” “CUSTOMER” “ADVISE” “REMITTER”
“KNOW” “REMITTER” “ADDITIONAL” “INFORMATION”
“ADDITIONAL” “INFO” “ADDITIONAL” “REFERENCES”
“ADDITIONAL” “REFS” “ADDITIONAL” “DETAILS”
“ADVISE” “BENEFICIARY” “DETAILS” “ADVISE” “BENEFICIARY” “INFORMATION”
“ADVISE” “BENEFICIARY” “INFO” “ADVISE” “BENEFICIARY” “REFERENCES”
“ADVISE” “BENEFICIARY” “REFS” “SEND US” “INFORMATION”
“SEND US” “INFO” “SEND US” “DETAILS”
“SEND US” “REFERENCES” “SEND US” “REFS”
“UNABLE” “PAYEE REQUIRES”
If found, the parser maps “UTC” to the WorkType property.
Locate Work Type = Unable to Apply Debit

right):
“UNABLE” “APPLY” “DEBIT” “NOT ABLE” “APPLY” “DEBIT”

“CANNOT” “APPLY” “DEBIT” “FURTHER DETAILS” “DEBIT”
“MORE DETAILS” “DEBIT” “ADDITIONAL DETAILS” “DEBIT”
“ADDITIONAL INFORMATION” “DEBIT” “ADDITIONAL INFO” “DEBIT”
“UNABLE” “IDENTIFY” “DEBIT” “NOT ABLE” “IDENTIFY” “DEBIT”
“CANNOT” “IDENTIFY” “DEBIT” :/47/
If found, the parser maps “UTD” to the WorkType property.
Locate Work Type = Unable to Effect Payment

right):
“UNABLE TO EXECUTE” “NOT ABLE TO EXECUTE”

“UNABLE TO EFFECT” “UNABLE TO PROCESS”
“NOT ABLE TO EFFECT” “PAYMENT ORDER” “INTENDED FOR US”
“NEED” “BENEFICIARY” “NEED” “BENEFICIARY BANK”

“NEED” “CORRESPONDENT BANK” “NEED” “FIELD57”
“NEED” “FIELD 57” “NEED” “BNF” “BANK”
“NEED” “PAYEE” “BANK” “HOLD” “ACCOUNT”
“HOLD” “A/C” “HOLD” “ACCT”
“NAME” “BANK” “BENEFICIARY” “CANNOT APPLY” “NAME” “NOT CORRECT”
“NAME” “NOT CORRECT” “CANNOT APPLY” “CANNOT APPLY” “NBR” “NOT CORRECT”
“CANNOT APPLY” “NBR” “INCORRECT” “BANK” “NAME” “BENEFICIARY”
“CLARIFICATION” “BANK” “BENEFICIARY” “BANK” “CLARIFICATION” “BENEFICIARY”
“NO ACCOUNT” “WITH US” “NO A/C” “WITH US”
“NO ACCT” “WITH US” “NO BEN ACC” “FURNISH US”
“CLARIFY CREDIT PARTY” “FIELD 57” “INCOMPLETE”
“FIELD57” “INCOMPLETE” “NOT MAINTAIN” “ACCOUNT”
“NOT MAINTAIN” “A/C” “NOT MAINTAIN” “ACCT”
“COMPLETE BANK” “COMPLETE BENEFICIARY”
“MISSING “DETAILS” “BANK” “MISSING “INFO” “BANK”
“MISSING “INFORMATION” “BANK” “ACCOUNT NOT HELD”
“ACCT NOT HELD” “A/C NOT HELD”
“NOT HELD WITH US” “{2:O103”
“{2:O202” “{2:I103”
“{2:I202” “BENEFICIARY UNKNOWN”
“ACCT” “CLOSED” “A/C” “CLOSED”
“ACCOUNT” “CLOSED” “MATCH”
“NAME DO NOT MATCH” “NUMBER” “NAME” “NOT FOUND”
“NUMBER DO NOT MATCH” “DIFFER”
“BENEFICIARY” “UNKNOWN” “ACCOUNT” “UNKNOWN”
“BENEFICIARY” “INCORRECT” “PROVIDE” “FULL” “BENEFICIARY”
“SUPPLY” “FULL” “BENEFICIARY” “PROVIDE” “FULL” “BENEFICIARY DETAILS”
“SUPPLY” “FULL” “BENEFICIARY DETAILS” “PROVIDE” “FULL” “BENEFICIARY NAME”
“SUPPLY” “FULL” “BENEFICIARY NAME” “PROVIDE” “CORRECT” “BEN”
“NAME IS INCORRECT” “ACCOUNT” “CORRECT”
“ACCT” “CORRECT” “A/C” “CORRECT”
“ACCOUNT” “INCORRECT” “ACCT” “INCORRECT”
“A/C” “INCORRECT” “ACCOUNT” “NOT VALID”
“ACCT” “NOT VALID” “A/C” “NOT VALID”
“ACCOUNT” “INVALID” “ACCT” “INVALID”
“A/C” “INVALID” “VALID” “ACCOUNT”
“VALID” “ACCT” “VALID” “A/C”
“NOT AGREE” “ACCOUNT NUMBER” “MISSING”
“ACCT NUMBER” “MISSING” “A/C NUMBER” “MISSING”
“NO ACCT NBR PROVIDED” “ADVISE CORRECT” “NAME”
“ADVISE” “BENEF” “CORRECT” “ADVISE” “BENE” “CORRECT”
“ADVISE” “BENEFICIARY” “CORRECT” “ADVISE” “BEN” “CORRECT”
“UNABLE TO APPLY” “PROVIDE” “DETAILS” “UNABLE TO APPLY” “FURNISH” “DETAILS”
“CANNOT” “NAME” “INCOMPLETE” “PROVIDE” “FURTHER DETAILS” “TO RE-EFFECT”
“CANNOT APPLY” “INEXACT” “:/5/”
“:/8/” “:/9/”
“:/38/” “:/43/”
“GIVE US” “BENEFICIARY” “SEND US” “BENEFICIARY”
“BENEFICIARY DETAILS” “FURTHER DETAILS” “TO RE-EFFECT”
“ADVISE” “PAYMENT” “INTENDED FOR US”
If found, the parser maps “UTE” to the WorkType property.

Appendix D: Accounting Step Rules
and Payment Types
This appendix lists the accounting step rules, payment types and accounting documents
configured in Smart Investigate for Payments.
To find accounting steps in the system:
From the Dev Studio, select App, enter the class PegaSI-Work-.
Click Technical, then Financial Adjustment Rule to see the list of all accounting
adjustment steps.
Double click any instance to open the rule. For example, the Adjustment Rule Return to
Sender:
Pega Smart Investigate for Payments Implementation Guide D-1

The Transactions tab shows the individual debit and credit entries, as well as payment types,
default amount and date values, and documents generated.
The following table shows the Smart Investigate for Payments accounting step rules and
the associated payment types and documents.
Transaction Name Debit/Credit Payment type Documents

number
Step (Adjustment Type): Reversal DR

TXN1 DCUS DR DCUS-CCUS-202- DCUSCCUS202
ADVICEOFDR
DCUS-CCUS-202 DCUSCCUS202
DCUS-CCUS-103- DCUSCCUS103
ADVICEOFDR
NO DOCUMENTS
DR ADVICE ONLY ADVICEOFDR
TXN2 CCUS CR CR ADVICE ONLY ADVICEOFCR
NO DOCUMENTS
Step (Adjustment Type): Reversal CR
TXN1 DCUS DR DCUS-CCUS-202- DCUSCCUS202
ADVICEOFDR
DCUS-CCUS-103- DCUSCCUS103
ADVICEOFDR
number
NO DOCUMENTS
TXN2 CCUS CR CR ADVICE ONLY ADVICEOFCR
NO DOCUMENTS
Step (Adjustment Type): Return To Sender
TXN1 DCUS DR DR ADVICE ONLY ADVICEOFDR
NO DOCUMENTS
TXN2 CCUS CR DCUS-SBK-103 DCUSSBK103
DCUS-SBK-103-ADV DCUSSBK103
ADVICEOFPAY
DCUS-SBK-202 DCUSSBK202
DCUS-SBK-202-ADV DCUSSBK202
ADVICEOFPAY
DCUS-REM-103 DCUSREM103
DCUS-REM-103-ADV DCUSREM103
ADVICEOFPAY
DCUS-REM-202-ADV DCUSREM202
ADVICEOFPAY
DCUS-BLANK-103-ADV DCUSBLANK103
ADVICEOFPAY
ADVICEOFPAY
DCUS-BLANK-103 DCUSBLANK103
CR ADVICE ONLY ADVICEOFPAY
NO DOCUMENTS
Step (Adjustment Type): Reeffect Payment
TXN DCUS DR DR ADVICE ONLY ADVICEOFDR
1
NO DOCUMENTS
TXN CCUS CR DCUS-BNF-103 DCUSBNF103
2
DCUS-BNF-103-ADV DCUSBNF103
ADVICEOFPAY
DCUS-BNF-202 DCUSBNF202
DCUS-BNF-202-ADV DCUSBNF202
ADVICEOFPAY
ADVICEOFPAY
ADVICEOFPAY

number
NO DOCUMENTS
Step (Adjustment Type): Reeffect Payment to New Beneficiary
TXN 1 DCUS DR DR ADVICE ONLY ADVICEOFDR
NO DOCUMENTS
TXN CCUS CR DCUS-NEWBNF-103 DCUSNEWBNF103
2
DCUS-NEWBNF-103-ADV DCUSNEWBNF103
ADVICEOFPAY
DCUS-NEWBNF-202 DCUSNEWBNF202
ADVICEOFPAY
ADVICEOFPAY
ADVICEOFPAY
NO DOCUMENTS
Step (Adjustment Type): Initiate Payment
1
NO DOCUMENTS
TXN 2 CCUS CR DCUS-BLANK-103-ADV DCUSBLANK103
ADVICEOFPAY
ADVICEOFPAY
NO DOCUMENTS
Step (Adjustment Type): Reeffect Cover
1
NO DOCUMENTS
TXN CCUS CR DCUS-RBK-202 DCUSRBK202
2
DCUS-RBK-202-ADV DCUSRBK202

number
ADVICEOFPAY
ADVICEOFPAY
NO DOCUMENTS
Step (Adjustment Type): Value Adjustment-Credit
1
DCUS-CWASH-202-ADV DCUSCWASH202
ADVICEOFDR
DCUS-CWASH-202 DCUSCWASH202
ADVICEOFDR
NO DOCUMENTS
TXN CCUS CR CR ADVICE ONLY ADVICEOFCR
2
DWASH-CCUS-202-ADV DWASHCCUS202
ADVICEOFCR
DWASH-CCUS-202 DWASHCCUS202
ADVICEOFCR
NO DOCUMENTS
Step (Adjustment Type): Value Adjustment-Debit
1
NO DOCUMENTS
TXN CCUS CR DCUS-NEWBNF-103 DCUSNEWBNF103
2
ADVICEOFPAY
DCUS-NEWBNF-202 DCUSNEWBNF202
ADVICEOFPAY

number
ADVICEOFPAY
ADVICEOFPAY
NO DOCUMENTS
Step (Adjustment Type): Internal Adjustment-Debit
TXN 1 DCUS DR DCUS-CCUS-202-ADV DCUSCCUS202
ADVICEOFDR
DCUS-CCUS-103-ADV DCUSCCUS103
ADVICEOFDR
NO DOCUMENTS
2
Step (Adjustment Type): Internal Adjustment-Credit
TXN 1 DCUS DR DCUS-CCUS-202-ADV DCUSCCUS202
ADVICEOFDR
DCUS-CCUS-103-ADV DCUSCCUS103
ADVICEOFDR
NO DOCUMENTS
2
NO DOCUMENTS
Step (Adjustment Type): Internal Adjustment-1DR / 2CR
1
ADVICEOFDR
ADVICEOFDR
NO DOCUMENTS

number
TXN 2 CCUS1 CR CR ADVICE ONLY ADVICEOFCR
DWASH-CCUS1-202-ADV DWASHCCUS1202
ADVICEOFCR
DWASH-CCUS1-202 DWASHCCUS1202
ADVICEOFCR
NO DOCUMENTS
TXN CCUS2 CR CR ADVICE ONLY ADVICEOFCR
3
ADVICEOFCR
ADVICEOFCR
NO DOCUMENTS
TXN 1 DCUS DR DR ADVICE ONLY ADVICEOFDR
ADVICEOFDR
ADVICEOFDR
NO DOCUMENTS
2
ADVICEOFCR
ADVICEOFCR
NO DOCUMENTS
3
ADVICEOFCR

number
ADVICEOFCR
NO DOCUMENTS
4
ADVICEOFCR
ADVICEOFCR
NO DOCUMENTS
TXN DCUS1 DR DR ADVICE ONLY ADVICEOFDR
1
DCUS1-CWASH-202-ADV DCUS1CWASH202
ADVICEOFDR
DCUS1-CWASH-202 DCUS1CWASH202
ADVICEOFDR
NO DOCUMENTS
TXN 2 DCUS2 DR DR ADVICE ONLY ADVICEOFDR
ADVICEOFDR
ADVICEOFDR
NO DOCUMENTS
3
ADVICEOFCR
ADVICEOFCR
NO DOCUMENTS

number

1
ADVICEOFDR
ADVICEOFDR
NO DOCUMENTS
2
ADVICEOFDR
ADVICEOFDR
NO DOCUMENTS
3
ADVICEOFDR
ADVICEOFDR
NO DOCUMENTS
TXN 4 CCUS CR CR ADVICE ONLY ADVICEOFCR
ADVICEOFCR
ADVICEOFCR
NO DOCUMENTS
1
ADVICEOFDR

number
ADVICEOFDR
NO DOCUMENTS
ADVICEOFDR
ADVICEOFDR
NO DOCUMENTS
3
ADVICEOFCR
ADVICEOFCR
NO DOCUMENTS
4
ADVICEOFCR
ADVICEOFCR
NO DOCUMENTS
ADVICEOFDR
ADVICEOFDR
NO DOCUMENTS

number

2
ADVICEOFDR
ADVICEOFDR
NO DOCUMENTS
3
ADVICEOFDR
ADVICEOFDR
NO DOCUMENTS
4
ADVICEOFCR
ADVICEOFCR
NO DOCUMENTS
5
ADVICEOFCR
ADVICEOFCR
NO DOCUMENTS
6
ADVICEOFCR

number
ADVICEOFCR
NO DOCUMENTS
ADVICEOFDR
ADVICEOFDR
NO DOCUMENTS
2
ADVICEOFDR
ADVICEOFDR
NO DOCUMENTS
3
ADVICEOFDR
ADVICEOFDR
NO DOCUMENTS
TXN 4 CCUS1 CR CR ADVICE ONLY ADVICEOFCR
ADVICEOFCR
ADVICEOFCR
NO DOCUMENTS
5

number
ADVICEOFCR
ADVICEOFCR
NO DOCUMENTS
ADVICEOFDR
ADVICEOFDR
NO DOCUMENTS
2
ADVICEOFDR
ADVICEOFDR
NO DOCUMENTS
3
ADVICEOFCR
ADVICEOFCR
NO DOCUMENTS
4
ADVICEOFCR
ADVICEOFCR

number
NO DOCUMENTS
5
ADVICEOFCR
ADVICEOFCR
NO DOCUMENTS
Step (Adjustment Type): Indemnity
TXN 1 DCUS DR DRAdviceOnlyIndemnity ADVICEOFDRIndem
TXN CCUS CR DCUSCCUS202Ind DCUSCCUS202Ind

2
DCUSCCUS202ADVIndFE DCUSCCUS202Ind
D ADVICEOFCRInd
NO DOCUMENTS
CRAdviceOnlyInd ADVICEOFCRInd
CRAdviceOnlyIndFED ADVICEOFCRInd

Appendix E: Compensation Step Rules
and Payment Types
This appendix lists the compensation step rules, payment types and documents configured
in Smart Investigate for Payments.
To find compensation steps in the system:
From the Dev Studio, select App, enter the class PegaSI-Compensation, click Technical,
then Financial Adjustment Rule to see the list of all compensation steps.
Double click on any rule to open the step rule form. For example, several tabs on
information are available for this back-value rule.
The Transactions tab shows the individual debit and credit entries, as well as payment
types, default amount and date values, and documents generated.
Pega Smart Investigate for Payments Implementation Guide E-1

number
Step (Adjustment Type): Inbound Back Value
TXN1 COMP CR COMPDWASHCCMPP20 DWASHCCMPP202
USE DR COMPDUSECWASH202 DUSECWASH202
RSV COMPDRSVCWASH202 DRSVCWASH202
FEE COMPDFEECWASH202 DFEECWASH202
2f BVFormDWASHCDBT202
BVFormDWASHCDBT202
newval
DCUS DR COMPDDCUSCWASH20 DDCUSCWASH202
BVFormDWASHCDBT202
newval
DCUS COMPDDCUSCWASH20 DDCUSCWASH202
Step (Adjustment Type): Inbound Back Value
TXN1 COMP DR COMPDCMPRCWASH20 DCMPRCWASH202
USE CR COMPDWASHCCMPP20 DWASHCCMPP202
RSV COMPDUSECWASH202 DUSECWASH202
FEE COMPDRSVCWASH202 DRSVCWASH202
SHORT DR COMPDFEECWASH202 DFEECWASH202
TXN2 COMP DR COMPDWASHCCMPP20 DWASHCCMPP202
BVFormDWASHCDBT202
newval
USE CR COMPDUSECWASH202 DUSECWASH202

number
TXN3 COMP DR COMPDWASHCCMPP20 DWASHCCMPP202
USE CR COMPDDCUSCWASH20 DDCUSCWASH202
RSV COMPDWASHCCMPP202f DWASHCCMPP202
BVFormDWASHCDBT202
BVFormDWASHCDBT202
newval
FEE COMPDUSECWASH202 DUSECWASH202
OVER DR COMPDDCUSCWASH202 DDCUSCWASH202
TXN4 COMP DR COMPDCMPRCWASH202 DCOMPRCWASH202
BVF BVFormDCDTCWASH202
BVFormDWASHCCDT202
USE CR COMPDWASHCUSE202 DWASHCUSE202
RSV COMPDWASHCRSV202 DWASHCRSV202
FEE COMPDWASHCFEE202 DWASHCFEE202
SHORT DR COMPDSHORTCWASH20 DSHORTCWASH202
BVFormDWASHCCDT202
BVFormDWASHCCDT202
OVER DR COMPDWASHCOVER202 DWASHCOVER202
CCUS CR COMPDWASHCCCUS202 DWASHCCCUS202
OVER DR COMPDWASHCOVER202 DWASHCOVER202

number
Step (Adjustment Type): Outbound Forward Value
FV FVFormDWASHCDBT202
FVFormDWASHCDBT202
newval
DCUS DR COMPDUSECWASH202 DUSECWASH202
Step (Adjustment Type): Inbound Forward Value

OVER COMPDWASHCOVER202 DWASHCOVER202
BVFormDWASHCCDT202
BVFormDWASHCCDT202

number
BVFormDWASHCCDT202
FVF BVFormDDBTCWASH202
BVFormDWASHCDBT202
BVFormDWASHCDBT202
BVFormDWASHCDBT202
CCUS CR COMPDWASHCUSE202 DWASHCUSE202
Step (Adjustment Type): Outbound Unjust Enrichment (Use of Funds)
FEE CR COMPDWASHCFEE202 DWASHCFEE202

number
FV FVFormDWASHCDBT202
FVFormDWASHCDBT202
newval
Step (Adjustment Type): Inbound Unjust Enrichment (Use of Funds)
FEE DR COMPDFEECWASH202 DFEECWASH202
OVER CR COMPDWASHCOVER202 DWASHCOVER202
BVFormDWASHCCDT202
BVFormDWASHCCDT202
BVFormDWASHCCDT202
BVFormDWASHCDBT202

number
BVFormDWASHCDBT202
BVFormDWASHCDBT202
Step (Adjustment Type): Outbound Amend Beneficiary
RSV DR COMPDRSVCWASH202 DRSVCWASH202
Step (Adjustment Type): Inbound Amend Beneficiary
RSV CR COMPDWASHCRSV202 DWASHCRSV202

Appendix F: Glossary
This glossary is included to assist you in understanding Smart Investigate for Payments
terms.
A
access group Determines the layout of a user’s home page and the user roles
available. System administrators define access groups and associate
access role Assigned to individual users to modify their access to rules. A rule of
type Rule- Access-Role-Name.
accounting cutoff A predetermined time of day when no more transactions are posted
for that day. Transactions entered after the cutoff are recorded on
accounting step The financial transaction that a workflow executes to generate
debit and credit entries for parties defined in the case.
action A workflow (business process) action. A rule of type Rule-Obj-
Administer bar Means of access to organization data, databases, security
data, RuleSets, integration services, and data reports.
age The length of time a work item has been pending completion.
Standard properties and reports track age as an indicator of how well
the organization is providing service.
agent A background internal thread operating on the server. Agents
periodically monitor conditions and perform processing as necessary.
assignment Assignments record a temporary condition of an open work object
within an executing flow that requires users or an external system to
act on the work object for it to progress to the next step.
attachment A file, image, scanned document, URL, or text note that has been
associated with a work object. A paper clip icon identifies
authentication The process of determining the identity of a new user or requestor
of services. Log-in is an authentication process.
automatic processing See background processing.
B
background processing Automatic processing, without operator intervention.
base amount The local currency equivalent of the inquiry amount.
beneficiary The final recipient of payment proceeds.
beneficiary bank The bank in which the beneficiary’s account is domiciled.
branch The location that is processing payment.
broadcast A short text message visible to users. An instance of Data-
Broadcast. Users can define distinct messages for each
C
case A collection of tasks or assignments that are completed to resolve an
Pega Smart Investigate for Payments Implementation Guide F-1

check in/check out Rule management process for a RuleSet, by which only one user at a time may
edit a rule so that multiple users cannot overwrite each other’s changes. When a
user checks out a rule, other users are barred from editing it (they can access it in
a read-only mode). When the rule is checked back in, it is again available to be
checked out.
CHIPS The Clearing House Interbank Payment System, used in the United States as the
final settlement payment system for business-to-business transactions.
class Rules of type Rule-Obj-Class. Do not confuse with Java classes.
class group A means to store instances from two or more concrete classes (that share a
common key format) in a single database table. Class groups are commonly used
to store instances of similar or related Work- concrete classes together in a
relational database table.
compensation The payment or acceptance of interest for late payments.
connector A programmatic component that defines and implements an interface between
Smart Investigate for Payments, acting as a client, and an external system, acting
as a server. Connectors are implemented through an instance of a connector rule.
context-sensitive The right side of the application portal, in which forms, lists, links, and toolbars are
workspace displayed as permitted by the user’s present action. For example, the toolbar
displays the check in/check out icons only when an open rule is under rule
management.
correct party An additional party added to the work object to replace any erroneous party within
the payment chain.
correspondence An outgoing e-mail message, printed letter, or facsimile transmission produced by
Smart Investigate for Payments and its users.
correspondence template Definition of the format, content, and type of correspondence; refers to a
correspondence rule.
Correspondence Output Server See PegaDISTRIBUTION Manager.
(COS)
cover thru An additional party in the payment chain facilitating the transmission of funds to
the paying bank.
credit party The party in the paying chain whose account was credited with the proceeds.
credit party account officer The officer managing the relationship/account of the credit party.
D
Dashboard bar Means of access to standard reports, accelerators and wizards, your operator
profile, and company news.
deadline The maximum time allowed to resolve a case, configured in a service level
agreement (SLA). See also goal.
debit party The party within the paying chain whose account was debited to make the
payment.

debit party account officer The officer managing the relationship/account of the debit party.
division The middle level of the standard three-level hierarchy. The organizational structure
affects management reports and statistics and the RuleSet visible to users in that
organization when they log in. An instance of Data-Admin-OrgDivision. See also
organization and unit.
E
EJB (Enterprise An architecture for setting up Java program components that run on servers.
JavaBeans)
escalation Processing within Smart Investigate for Payments that causes high-priority cases
to become more visible to users and managers. The urgency property determines
the order of cases in worklists. In some cases, the escalation process can
recalculate the urgency value.
F
Fed Service A means of interbank communication used in North America.
federal funds rate The interest rate at which depository institutions lend balances at the Federal
Reserve to other depository institutions overnight.
Federal Funds Transfer System A high-speed electronic payment system owned and operated by the Federal
Reserve Banks, which act as intermediaries (though not counterparties) in all
Fedwire funds transfers for Fedwire participants.
Fedwire A funds transfer system owned and operated by the Federal Reserve System.
financial case A case with suspense accounting activities.
flow See workflow.
G
gadget See section.
goal The expected time to resolve a case, configured in a service level agreement
(SLA). See also deadline.
H
home view Sections of task-based links relevant to a workspace. When the workspace is
displaying lists, forms, and so forth, clicking on a bar displays its home view.
I
IMAD (Input Message A unique number assigned to track each Fedwire transaction sent by a financial
Accountability Data) institution.
indemnity A request from one bank to another to expedite action on an exception without
going through the normal exception process, with an assurance that all fees will be
paid.
instance An object — a collection of values and methods associated with a class.
inquirer The party requesting investigation or information.
intent-led flow A workflow that guides users to do the right thing in a given processing situation by
presenting appropriate choices based on data and context.
interaction Communication between a contact and the organization. This communication can
include live interactions, such as telephone calls and branch location visits, or non-
live interactions such as e-mail or mail.
intermediary bank A third-party bank used in the payment chain to facilitate payment between
banking entities who do not have a direct relationship with each other.
IOS See PegaDISTRIBUTION MANAGER.
item ID An identification number (stored in the property .pyID) automatically assigned to a
case.
J
J2EE Java 2 Enterprise Edition.
JAR Java ARchive, a file format based on the ZIP compressed-file format. A JAR file
aggregates many files into one.
Java servlet See servlet.
L
line of business (LOB) A type of operation area dealing with process.
M
Manage Rules bar Means of access to rules and classes via the explorers; to business, system, and
integration rules by search criteria; to service, connector, property, and process
configuration; and to rule reports.
MQ messaging An IBM message protocol.
N
navigation panel The left side of the application portal, which contains a series of bars that group
controls by function.
nonfinancial case A case that has no suspense accounting activity.
O
ODBC Open DataBase Connectivity. A common language to gain access to a database
on a network.
Oracle Relational database software providing access to the Oracle calls used in Smart
organization The top level of the standard three-level hierarchy. The organizational structure
affects management reports and statistics and the RuleSet visible to users in that
organization when they log in. An instance of Data-Admin-Organization. See also
division and unit.
P
page The standard Smart Investigate for Payments Web interface. The portal rule
defines tabs and the arrangement and labeling of tools and features on them.
party A person or entity involved in a case; for example, a customer, a bank, or an
internal department.

PegaDISTRIBUTION An output correspondence server that sends HTML or Microsoft Word documents
MANAGER from PegaRULES Process Commander to channels available on other systems.
Correspondence can be printed, faxed, or saved in RTF format. Formerly called
IOS (ImageNet Output Server).
PegaRESEARCH Manager A Pegasystems product that provides a central repository for critical SWIFT
messages and transaction data. PegaRESEARCH Manager can retrieve SWIFT
transactions and map the results into a case.
pegarules.xml file A small XML file on each Process Commander system and node that defines
various installation and startup parameters.
portal See page.
privilege An access control element associated with a class and an access role. A rule of
type Rule-Access-Privilege. Privileges offer finer tuning of access control than
access roles alone. To have access to a privilege, a user must have at least one of
the access roles that grants access to the privilege in an access role list. The
association between access roles and privileges is established in rules of type
Rule-Access-Role-Obj.
process architect A business user or business analyst who defines and maintains business rules,
service levels, and flows or processes.
Process Work bar Provides access to your worklist and workbaskets. Use to search, select, and
process work on your worklist, manage workbaskets, and transfer work among
operators.
PRPC PegaRULES Process Commander.
R
reference number See item ID.
receiving bank The bank receiving the payment.
receiving bank The bank representing the receiving bank in the payment chain.
correspondent
remitter The party on whose behalf the payment is made.
remitting bank The bank initiating the payment, usually holds the account of the remitter.
remitting bank The bank holding a relationship with the remitting bank.
correspondent
Reports bar Means of access to reports and tools for monitoring assignments and processes,
analyzing process quality, and analyzing process performance.
route An activity that determines which user worklist or which workbasket is to receive
an assignment.
RuleSet A group of related object classes, workflows, and business rules.
RuleSet hierarchy The ordered list of RuleSets in Process Commander applications. The most
general RuleSets that provide basic functions are at the bottom, RuleSets specific
to your application are in the middle, and RuleSets customized for your
organization are at the top.
S

section Also called a gadget, a rectangular area on a page containing a control that a user
can interact with. For example, the worklist area of the user’s home page is
implemented through a gadget.
Sections are instances of Data-Gadget. By creating portal rules (of type Rule-
Portal), system architects determine the appearance, labeling, and location of
sections on the home page (portal), and which parts of the portal are visible to
different groups of users.
sending bank The bank sending the payment.
service A programmatic component that defines and implements an interface between an
external application, acting as a client, and the Smart Investigate for Payments
system, acting as a server.
An external system may use any of several technical frameworks to call Smart
Investigate for Payments, become a requestor of an appropriate type, send a
request, execute an activity (which may call other activities, update data, and start
other processing), and receive the results in a response.
A service is implemented through an instance of a service rule, plus in some cases

appropriate programming code in the initiating application or system.
See also connector.

service level Time interval to complete a request. Each service level rule defines one or two-
t i m e intervals, known as goals and deadlines that indicate the expected or
targeted turnaround time for the assignment, or time to resolve for the case.
Simple Object Access Protocol A protocol used to exchange information in a decentralized, distributed
(SOAP) environment. SOAP is an XML-based protocol.
SLA Service level agreement. See service level.
SmartPrompt A text box used on many forms that dynamically creates a selection list of valid
selections for fast user data entry. A blue triangle in the lower-right corner
identifies SmartPrompt text boxes.
SnapStart A data import facility used to generate and prepopulate Process Commander work
objects from an external application, without a user log-in process. Note that
SnapStart itself does not authenticate — it sends a user ID and password within
the URL.
SOAP services A collection of functions that applications can call using the SOAP protocol.
step The primary processing unit of an activity or business process.
step-by-step The manual ordering and initiation of a processing step, performed manually by a
user outside automated workflow processing. Once a case is placed in a step-by-
step assignment, it exits the automated flow and cannot reenter it.
straight-through Automatic processing that occurs without operator intervention.
processing (STP)

SWIFT Society for Worldwide Interbank Financial Telecommunication. A secure network
supporting the dispatch and receipt of payments, inquiry, and advice messages
between banks and financial institutions.
Pegasystems is an official SWIFT solution partner. Refer to www.swift.com for

further information.
SWIFTNet The implementation of the SWIFT messaging protocol using a secure IP network.
system administrator A systems engineer who is responsible for installation and setup, security, and
other operational functions.
system architect An application developer who creates the class structure for your work with
supporting automation capabilities and implements interfaces with external
systems.
T
third reimbursement bank The party in the cover payment chain included to facilitate transmission of funds to
the paying bank.
tickler A reminder message, sent when no response has been received from a previous
inquiry. Also known as chaser or tracer.
Tools bar Provides access to system tools such as the Rules Inspector and Clipboard.
TRN Transaction.
U
unit The bottom level of the standard three-level hierarchy. The organizational
structure affects management reports and statistics and the RuleSet visible to
users in that organization when they log in. An instance of Data-Admin-OrgUnit.
See also division and organization.
urgency A numeric value between 0 and 100 that defines the importance of speed in
completing and resolving an assignment. Urgency defines the order in which
cases appear on a user’s worklist. Larger values correspond to higher importance.
Urgency can be changed by users, managers, or the system based on service
levels, dollar amounts, special treatment for special customers, backlog, or other
conditions.
URI (Universal Resource Information pertaining to the location of a particular resource on the server. For
Identifier) example, in the URL http://webserve/servlet/admin/?contents.html, the URI is
/servlet/admin.
V
verification A task performed by a person who is double-checking prior work to catch possible
mistakes or variances with policy before the work becomes final. Verification is
common in financial processes involving large sums, sensitive legal commitments,
or correspondence.
W
Web application server See application server.
Web service A service using the SOAP protocol to transmit XML-formatted messages.

workbasket A centralized, shared pool of work objects from which users select work.
work object A unit of work.
workflow A standard set of steps that resolves a case.
worklist A list of items assigned to a specific user, ordered by priority.
work type The reason for an exception.

Pega Smart Investigate Payments 8.3 Implementation Guide

Uploaded by

Copyright:

Available Formats

Pega Smart Investigate Payments 8.3 Implementation Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Pega Smart Investigate Payments 8.3 Implementation Guide

Uploaded by

Copyright:

Available Formats

What is the purpose of this document?

What is the purpose of this document?

What are some of the main terms defined in the glossary?

What are some of the main terms defined in the glossary?

Pega Smart Investigate for

This information is the property of:

Pega Smart Investigate for Payments

Document: Implementation Guide

Software Version: 8.2

Updated: November 2019

Understanding the Basics ........................................................................................... 2-1

Deploying the application ........................................................................................... 3-1

Setting up accounting functions ................................................................................ 4-1

Setting up your organization ....................................................................................... 5-1

Integrating Smart Investigate ....................................................................................... 6-1

Understanding Reports and Report Scheduling ....................................................... 7-1

Appendix A: Application-Specific Information......................................................... A-1

Appendix B: Sample Modeler Workflows ................................................................ B-1

Appendix C: Text Parsing Rules ............................................................................... C-1

Appendix D: Accounting Step Rules and Payment Types ...................................... D-1

Appendix E: Compensation Step Rules and Payment Types ..................................E-1

Appendix F: Glossary .................................................................................................. F-1

Pega Smart Investigate for Payments Implementation Guide 1-1

Pega Smart Investigate for Payments Implementation Guide 1-2

Pega Smart Investigate for Payments Implementation Guide 1-3

This chapter includes the following topics:

You begin customizing your application environment by duplicating existing Pega 8

Pega Smart Investigate for Payments Implementation Guide 2-1

Pega Smart Investigate for Payments Implementation Guide 2-2

• Highest Level: Organization — identifies the company entity.

Pega Smart Investigate for Payments Implementation Guide 2-3

Pega Smart Investigate for Payments Implementation Guide 2-4

• The M- prefix is used for message cases.

Workbasket and Worklist Assignment Models

A worklist, automatically created for each operator ID (user), is a prioritized list of

Assignments can be transferred from a workbasket to a worklist in various ways:

• The system can automatically route assignments to a user’s worklist

Pega Smart Investigate for Payments Implementation Guide 2-5

Operators, Access Groups, and Access Roles

Pega Smart Investigate for Payments Implementation Guide 2-6

System Administrator SIPaymentsDev@pega.co SISysAdmin Developer SysAdmin

In addition, standard access roles are available, including the following:

• PegaRULES:SysAdm4 for users with system administrator responsibilities

Security of the Working Environment

Pega Smart Investigate for Payments Implementation Guide 2-7

Smart Investigate for Payments Security Levels

Rule Resolution and the User RuleSet List

Pega Smart Investigate for Payments Implementation Guide 2-9

Pega Smart Investigate for Payments Implementation Guide 2-10

The Power and Flexibility of Ruleset Design

Integrating with External Systems

Pega Smart Investigate for Payments Implementation Guide 2-11

Pega Smart Investigate for Payments Implementation Guide 2-12

The topics covered in this chapter include:

• Overview of major deployment steps

The Ruleset Hierarchy

Pega Smart Investigate for Payments Implementation Guide 3-1

Creating Your Top-Level Class

Copying MyCoSI-Work to Your Class Hierarchy

• Smart Investigate for Payments Sample application is already installed.