SDK - Workflow Implementation Guide - FusionBanking Trade Innovation 27

Misys FusionBanking Trade Innovation 2.
SDK - Workflow
Implementation Guide
Version 1.0
Copyright
© Misys Limited, or a member of the Misys group of companies, 2014. All Rights Reserved. Confidential - Limited Distribution to
Authorized Persons Only, pursuant to the Terms of the License Agreement by which you were granted a license for the applicable
software licensed from Misys and/or an affiliate of Misys (“Software”) and associated documentation (“Documentation”).
Republication or redistribution, in whole or in part, of the content of this documentation or any other materials made available by
Misys is prohibited without the prior written consent of Misys. The Software and Documentation are protected as unpublished work
and constitute a trade secret of Misys Limited, or a member of the Misys group of companies, Head Office: One Kingdom Street,
Paddington, London W2 6BL.
Disclaimer
Misys does not guarantee that any information contained herein is and will remain accurate or that use of the information will
ensure correct and faultless operation of the relevant service or equipment. Misys, its agents, and employees shall not be held
liable to or through any user for any loss or damage whatsoever resulting from reliance on the information contained herein or
related thereto. This document contains information proprietary to Misys. Misys does not undertake mathematical research but only
applies mathematical models recognized within the financial industry. Misys does not guarantee the intrinsic theoretical validity of
the calculation models used. It is the obligation of the customer to ensure that responsible decisions are taken when using Misys
products.
Feedback
Do you have comments about our guides and online help? Please address any comments and questions to your local Misys
representative.
Need more information? Read more about our products at http://www.misys.com/software or contact your local Misys office
at http://www.misys.com/contact-us.aspx.
Release month and year: October 2015

Contents
Contents
Introduction ........................................................................................................................................... 1
FusionBanking Trade Innovation and Workflow ..................................................................................... 1
What is Advanced Workflow? ................................................................................................................. 1
Rejection Workflows .......................................................................................................................................... 2
Varying the Data in Each Step ........................................................................................................................... 2
The Use of Other SDK Components in Workflow ................................................................................... 2
Integration between Workflows and Other Systems .......................................................................................... 3
Integration between FusionBanking Trade Innovation and Other Systems ....................................................... 3
Licensing Levels of Workflow – ‘Standard’ and ‘Advanced’.................................................................... 3
Workflow Overview ............................................................................................................................... 4
The Basic Components of Workflow ....................................................................................................... 4
The Event Phases within Workflow ......................................................................................................... 5
The Standard (Default) Workflow Orchestration ..................................................................................... 6
Creating Steps for Bank Defined (Advanced) Workflows ....................................................................... 7
Sequencing Steps into Templates .......................................................................................................... 8
Data Capture Phase .......................................................................................................................................... 8
Verification Phase .............................................................................................................................................. 9
Post Release Phase .......................................................................................................................................... 9
Example Parallel Workflow ................................................................................................................................ 9
Example Parallel Workflow Utilising Reject Step Branch ................................................................................. 10
System Managed Steps ........................................................................................................................ 12
Limit Checking Automation ................................................................................................................... 13
Configuring Orchestrations ................................................................................................................... 13
Orchestrations under Advanced Workflow ....................................................................................................... 14
Exchange Steps .................................................................................................................................... 16
External Review Steps .......................................................................................................................... 16
Configuring Fields Available in Log or Input Steps ............................................................................... 16
The Dashboard and Master Browser .................................................................................................... 17
Watch List Checking ............................................................................................................................. 18
Populating an External Dashboard ....................................................................................................... 18
Populating a Dashboard from External Data ........................................................................................ 19
Accessing a Master or Event Step from an External System ............................................................... 19
Accessing an External System from the Application List ...................................................................... 20
Implementing Advanced Workflow Orchestrations ........................................................................ 21
The Default Steps ................................................................................................................................. 21
The Default Template............................................................................................................................ 22
The Default Orchestrations Parameter Set ........................................................................................... 22
© Misys | SDK - Workflow Implementation Guide - FusionBanking Trade Innovation 2.7 iii
Contents
The Default Workflow Orchestrations ................................................................................................... 23

Configuring Orchestrations and Parameter Set Conditions under Advanced Workflow ...................... 23
Maintaining and Creating New Steps ............................................................................................................... 23
Maintaining Templates Available to Orchestrations ......................................................................................... 25
Defaulting & Maintaining SLA Step Times ............................................................................................ 27
Defaulting & Maintaining Orchestration Parameters ............................................................................. 28
Setting up Step User Roles ................................................................................................................... 29
Configuring Workflow Orchestration ................................................................................................ 31
Orchestration Parameter Sets............................................................................................................... 31
Orchestration Setting Options ............................................................................................................... 33
Configuring Initial Steps & Reject-to Steps ...................................................................................................... 33
Configuring Step Conditions ............................................................................................................................ 35
Configuring SLA Step Times............................................................................................................................ 36
Viewing Progress against SLA Times .............................................................................................................. 38
Handling of Steps with Conditions ................................................................................................................... 38
Configuring Release Item Validation................................................................................................................ 39
Additional Workflow Orchestration Step Interaction ...................................................................... 40
Configuring Limit Checking/Reservation ............................................................................................... 40
Options Controlling Limit Checking/Reservation .............................................................................................. 40
Step Completing without Re-reservation Required .......................................................................................... 41
Check Completing without User Approval ....................................................................................................... 41
Check Requiring User Approval....................................................................................................................... 41
Configuring Watch List Checking .......................................................................................................... 41
Watch List Checking Step Execution .................................................................................................... 43
Check without User Interaction ........................................................................................................................ 44
Check Followed by User Override ................................................................................................................... 45
Configuring External Review Steps ...................................................................................................... 46
Step Response Field Customisation Setup ..................................................................................................... 46
Step Document Setup ...................................................................................................................................... 48
External Review Step Execution ........................................................................................................... 49
Example External Review Deferred Response Message ................................................................................ 50
Error and Warning Responses......................................................................................................................... 51
Check without User Interaction ........................................................................................................................ 52
Check followed by User Override .................................................................................................................... 53
Configuring Exchange Steps................................................................................................................. 54
Step Document Setup ...................................................................................................................................... 54
Exchange Step Execution ..................................................................................................................... 56
Check followed by User Confirm or Repair ...................................................................................................... 62
Available Balance Checking ................................................................................................................. 64
Step Handling under Reject and Abort Actions..................................................................................... 64
Updating In-use Orchestrations where Events are in Progress ............................................................ 64
© Misys | SDK - Workflow Implementation Guide - FusionBanking Trade Innovation 2.7 iv

Contents
Removing Obsolete Orchestrations ...................................................................................................... 64

Using Workflow in Conjunction with Provisional Events ....................................................................... 65
Using Workflow in Conjunction with Subsidiary Events ........................................................................ 65
Input, Review & Final Review Steps User Control ................................................................................ 65
Monitoring Workflow Events.............................................................................................................. 67
Overview ............................................................................................................................................... 67
The Dashboard ..................................................................................................................................... 67
Step status monitoring on the Dashboard ........................................................................................................ 69
Populating an External Dashboard ....................................................................................................... 69
The Master Browser .............................................................................................................................. 69
Monitoring Master Details on the Master Browser ........................................................................................... 70
Monitoring Event Details on the Master Browser ............................................................................................. 70
Step status monitoring on the Master Browser ................................................................................................ 71
The Master Summary............................................................................................................................ 72
Step Status Monitoring on the Master Summary ............................................................................................. 72
Step History & Step Status History ....................................................................................................... 72
Monitoring SLA Step Times .................................................................................................................. 73
Transaction Times ........................................................................................................................................... 73
Step Times....................................................................................................................................................... 74
Gateway Step Response Messages Repair ......................................................................................... 75
Errors and Warnings Presented Across Parallel Steps ........................................................................ 76
User-defined Warnings optionally re-issued under review verification ................................................. 76
Event Field Requirements under Parallel Step Model .......................................................................... 77
Appendix A Example Workflow for a Hub and Spoke Operation ................................................... 79
Setting up Routing to Teams and Users ............................................................................................... 79
Initial Routing to Teams or Team/Users on Event Creation ............................................................................. 80
Routing to Teams or Team/Users on Change of Step ..................................................................................... 80
Setting up Teams with User Roles ........................................................................................................ 80
Identifying the User Roles ................................................................................................................................ 81
Assigning Steps to User Roles ........................................................................................................................ 82
Identifying Teams ............................................................................................................................................ 84
Assigning Roles to Teams ............................................................................................................................... 84
Setting up Teams with User Roles ........................................................................................................ 84
Assigning Users to Teams ............................................................................................................................... 84
Setting up Users in Teams .................................................................................................................... 85
Appendix B SDK Components in Action .......................................................................................... 87
Appendix C Associated Documentation........................................................................................... 88
Glossary of Terms............................................................................................................................... 89
© Misys | SDK - Workflow Implementation Guide - FusionBanking Trade Innovation 2.7 v

Preface
Preface
This Guide provides an introduction to the capabilities of advanced workflow which is a key
component of the SDK – Advanced package.
The Guide contains the following chapters:
Chapter Description
Chapter 1 Provides an introduction to the principles of advanced workflow.
Chapter 2 Provides an overview of advanced workflow.
Chapter 3 Discusses how a bank should go about implementing advanced workflow.
Chapter 4 Covers the configuration requirements within Orchestrations type parameter sets.
Chapter 5 Covers the configuration options that need to be set up to support advanced workflow
processing. It explains how each is set, and the dependencies between them.
Chapter 6 Explains how the dashboard allows users to monitor their workflows and, if supervisors, the
workloads of their teams. It explains how an external dashboard can be maintained.
Appendix A Provides an example hub and spoke operation using advanced workflow orchestration.
Appendix B Provides an example of many of the other software development kit (SDK) components in
action.
Appendix C Provides a list of associated documentation.
Glossary of Provides a list of special terms used in this Guide and explains what each means.
Terms
Screen Examples
This guide includes examples of screens. The screens shown in your system may not look the same
as the examples in this guide. However the actual content and user operation are identical.
© Misys | SDK - Workflow Implementation Guide - FusionBanking Trade Innovation 2.7 vi

Preface
Document Conventions
The convention used in the Guide for identifying links accessed via drop-down lists from other links is
to cite the name of the first link, followed by name of the second link separated from it by a '|'
character - for example, ‘Other|FX Calculator'.
This format is used for notes that contain information of more than usual significance, such as
warnings or hints on using the software.
In the tables listing fields in windows, a tick next to a field indicates that the field is mandatory.
Further Reading
The system is supported by a comprehensive documentation set, which includes user guides for each
FusionBanking Trade Innovation product:
• Documentation Overview – FusionBanking Trade Innovation lists each of the documents in
the set and explains what it covers.
• Global Processing Implementation Guide – FusionBanking Trade Innovation sets the context
for transaction processing within a regional or global hub and spoke environment.
• Common Facilities User Guide – FusionBanking Trade Innovation explains common screen
elements shared by FusionBanking Trade Innovation products and is referred to where
required in this guide.
The following technical guides support workflow set-up:
• SDK – Common Facilities Guide – FusionBanking Trade Innovation
• SDK – Systems Interfacing Guide – FusionBanking Trade Innovation
• SDK – Systems Integration Guide – FusionBanking Trade Innovation
• SDK - Application Extension Guide – FusionBanking Trade Innovation
• SDK – Screen Tailoring Guide – FusionBanking Trade Innovation
• SDK – Data Management Guide – FusionBanking Trade Innovation
These are referenced where applicable in the sections that follow.
© Misys | SDK - Workflow Implementation Guide - FusionBanking Trade Innovation 2.7 vii
Introduction
Introduction
This chapter provides an introduction to the workflow and introduces some of the key terminology
used by the system with regard to workflow.
Not all features mentioned in this guide may be available to your bank. Some features are only
available if your bank is using the Advanced Software Development Kit (SDK). The guide indicates
where this is the case.
FusionBanking Trade Innovation and Workflow

The system is designed to support the complex workflow requirements of a trade finance bank. The
system enables a bank to operate either regionally or globally using a spoke and hub type workflow
set up. Within this set up workflows can be configured where processes occur in parallel. In addition
external systems can participate in the process by providing some of the data capture or responding
to external check requests using XML messaging. All messaging interaction is retained for audit
purposes.
In such a setup a bank can offer a local customer facing service in the spoke part of the workflow, for
example receiving and scanning documents from a customer, signature verification, negotiating FX
contracts and checking limits and printing out documents for the customer. The hub part of the
workflow can provide a centralised centre of excellence for further data entry and for checking the
workability of the customers’ requests. The hub would typically complete the data entry and any
additional checks such as for watch list compliance. The transaction would then proceed through one
or more review steps before items such as SWIFT messages and accounting entries are released.
The system comes with a delivered set of workflow steps, sequences and conditions. These or new
bank defined workflows can be configured for each transaction event according to the bank’s needs.
This is known as a workflow orchestration.
Advanced workflow allows additional instances of steps to be defined and placed into sequences in
templates. Multiple log, input, external checks, review and post release steps may be defined. Data
capture and limit checking steps comprise a linear sequence. Review and external checks can be
configured in parallel to maximise SLA time efficiency. Post release steps and print steps can also be
scheduled in parallel. Special exception workflows can be configured and these are known as
rejection workflows. A capability is provided to security users to allow reject back to any valid previous
step in the workflow.
What is Advanced Workflow?

Advanced workflow allows the bank to define extended sequences of steps to allow multiple log,
input, external checks, reviews and print steps. Four additional types of step are available exclusively
under advanced workflow:
• Exchange steps: A data capture input step where the data is provided from an external
system. Required event field tags are passed by an XML gateway message to the external
systems defined as a service in the system. The external system populates the required tags
with data and these then update the data within an exchange step in the system. A user can
accept, reject or repair the changes received. Where the data is accepted it updates the event
data and this can include any data extension fields added by your bank.
• External review steps: A specific check request. Response fields can be defined per step.
Responses are stored against the step and can be reviewed historically. A successful
response can optionally auto-complete the step.
© Misys | SDK - Workflow Implementation Guide - FusionBanking Trade Innovation 2.7 1

Introduction
• Synchronisation steps: To facilitate parallel linkages, this provides a stage gate (pinch point)
where multiple steps must complete before a following group of steps can commence. The
synchronisation step performs no processing in itself.
• Post release steps: Available to be mapped alongside print steps after release. These allow
senior management review of transactions undertaken.
Advanced workflow allows the bank to define additional steps of each basic type. In turn templates of
defined step in sequences can be defined. Within certain constraints these steps can be configured in
parallel to each other. Some step types are available to be included throughout logging, input and
final review phases.
Rejection Workflows
Additionally separate reject sequences can be defined for exception handling. This can provide for
example, within a complex workflow, the ability to reject back to a single input step to correct a certain
item and then review once before release. This circumvents passing again through the whole review
section after a data correction. An example of this would be the correction of an issue date for an
event which takes a number of days to issue where all the bank wishes to do is reset the issue date
and then recalculate any outputs accordingly without any other data changes. In such cases
additional software development kit (SDK) features can be used such as the ability to hide fields or
show them as view only so that only the issue date field is input capable.
Rejection target steps, execution conditions and SLA step times are configurable for all the steps
within the workflow orchestration. The default orchestrations parameter set provides the standard
orchestration configuration for all events implemented. Advanced workflow allows further parameter
sets to be defined for required parts of the business to run events according to enhanced template
dependency sequences. The execution conditions of the additional steps are managed in the
workflow orchestration definition. The default orchestrations can also be enhanced to use new step
templates and conditions if required.
Advanced workflow handles rejection under parallelism. Rejecting within one parallel line may require
the cancellation of the associated parallel activity. These steps will be subsequently repeated. SLA
step times includes all previous time taken within each step. Limit reservations can be included at
multiple points within data capture and reject sequences. The watch list check can be undertaken and
repeated at multiple points within a workflow. If an event is aborted, all active steps are cancelled.
Varying the Data in Each Step

Advanced workflow allows the fields included in steps to be shown, hidden or presented as view only
per individual step, for example a basic log could be configured with basic detail available and a
detailed log step can follow it allowing additional data to be included. Sections of the input screen can
be initially presented pre-collapsed for any step to avoid screen clutter. If the user needs to enter data
relevant to the collapsed section then they can open it up to enter the data.
The Use of Other SDK Components in Workflow

Workflow orchestration is provided within SDK as part of the system tailoring application and does not
require any particular technical skills.
To utilise the full power of workflow and the ability to exchange information with other systems a
number of other SDK technical features can be used.
Appendix B provides a high level example of usage, illustrating where other SDK components can be
used in conjunction with the advanced workflow features discussed in this Guide.

Introduction
Integration between Workflows and Other Systems

Advanced workflow allows external system to exchange data with the system to enrich the data in the
system’s event.
• The step type of Exchange allows data to be input to the event from an external source.
Required populated or unpopulated data is passed out to the external system where required
data is provide or updated using gateway messages. Documents can also be attached using
this mechanism.
Advanced workflow allows external system to provide verification query responses to the system. This
is separate to data input and so can be undertaken in parallel.
• The step type of External review allows query responses to be received from an external
source. Required context data is passed out to the external system. The responses are
received using gateway messages using customisation for the step.
Integration between FusionBanking Trade Innovation and Other

Systems
Advanced workflow allows forms of data integration and communication between systems. These
include:
• Event step status data can be published to external systems so that a dashboard of the
transaction status for trade finance transactions can be shown in that system.
• Transaction data from an external system can be mapped into a proxy zone for that data in
order that the cross-zone dashboard can include the external system’s transaction status
information. It is possible to set up a link to the transaction data in the external system, from
the dashboard.
• From an external system a user with appropriate common authentication rights can enquire or
continue the system’s events by accessing the master summary details or the event directly.
If configured, the user can then return to the external application.
The users may need access to certain external systems as part of their workflow activities. External
system URL links can be configured and made available on the applications list. Applications are
assigned to teams/users using capabilities. Common authentication provides seamless access. A
similar navigation can be set up to return to the system after the user has finished using the external
system.
Licensing Levels of Workflow – ‘Standard’ and ‘Advanced’

If a bank has licensed SDK ‘Lite’, then only the default steps and orchestration can be used for
workflow configuration within the zone.
If the bank has licensed SDK ‘Advanced’, then all of the features in this guide are available.
The intermediate license level SDK ‘Standard’ provides the following:
• Steps of any type can be created, except exchange and external review.
• Templates can be defined comprising any available steps in a linear sequence; however no
parallel or rejection flows can be defined.
• Monitoring SLA step times for each step within transactions.
• Ability to hide fields or make them read only according to the event step context.

Workflow Overview
Workflow Overview
This chapter provides an overview of the workflow, use of the dashboard for managing workloads and
features that enable closer integration with other departments and systems within a bank. The key
features include the following:
• A workflow can include multiple log and input steps within data capture.
• Including exchange steps within data capture allows input data to be received from an
external source.
• Non data capture steps can be scheduled to be run in parallel within data capture, verification
and post release phases.
• A graphical diagram illustrates the created workflow steps and dependency sequences.
• A generic verification step type that obtains a customisable, structured response from an
external system, to store external check responses.
• Ability to hide fields or make them read only according to the event step context.
The Basic Components of Workflow

The basic steps, log, input, review, final print etc., are available as types. Under standard workflow
there is one of each type. Advanced workflow allows more to be created for multiple use. In addition
four more step types are available for data exchange, external review, synchronisation points and
post release.
Steps are arranged into a template dependency sequence. Orchestrations take template sequences
to add conditions for a specific event context. This enables your bank to vary the steps required for
different events. For example when issuing a letter of credit you will probably require a limit check
step, whereas if you are just corresponding with another party you probably do not require the limit
check step. The template contains all the steps in dependency sequence. It is the workflow
orchestration for each event that determines the conditions under which each step in the template
occurs.
Orchestrations are defined within parameter sets where they can be made effective for a branch
scope context. This enables your bank to vary the workflow for different areas of the business.
In order to exchange data with other systems step level templates can be created that specify the
data to be sent to the external systems for different types of requests.

Workflow Overview
This diagram shows the inter-relationship between the components and these are discussed in more
detail throughout this document.
The Event Phases within Workflow

Steps of each type can be mapped within certain phases of the lifecycle of an event. There are three
phases:
• Data capture – can enter/update event data and review – can reject back
• Verification – review of data, no data entry – can reject back
• Post release – print and review data AFTER outputs released – no rejection allowed.
The internal create and release phases are managed automatically by the system and are not visible
to a user.

Workflow Overview
Before mapping new steps, note that the system is pre-delivered with standard default orchestration
mappings for all products’ steps in the default parameter set.
The Standard (Default) Workflow Orchestration
This workflow sequence provides the standard workflow for the system. In the diagram the steps in
grey circles are the internal system phases. All steps are located within the phases of an event. The
phases described here also include internal phases which manage system generated steps. These
are described in more detail later.
Creation phase (system creates the event on manual, batch, gateway or SWIFT message action)
Data capture phase (allows data entry)
• Log step
• Limit check step (for log step)
• Input step Final limit check step (provided by the system at the end of data capture if the
required reservation has not already been made)
• Watch list check step
Verification phase (no data can be added or changed)
• Review step
• Final review step (allows authorisation of the event)
Release phase (internal conditions checks prior to release of the transaction)
Post release phase

Workflow Overview
• Print step (for final print)

This step sequence is set in a standard template used for all events in the standard configuration.
Each orchestration has standard settings for initial steps, final print steps and rejection target steps.
With advanced workflow you can change the underlying template used enabling new sequences to be
used.
Creating Steps for Bank Defined (Advanced) Workflows

Under advanced workflow step definitions can be created of each basic type for assembling into
sequences known as templates.
Steps can be created of the following types:
• Log type
• Limit check type
• Final limit check type
• Watch list check type
• Input type
• Exchange type (input from an external system – updates event data, cannot run in parallel)
• Review type (additionally configurable as final)
• External review type (external check response - updates step data, can run in parallel)
• Synchronisation type (for creating a single stage gate between multiple steps before and
after)
• Print type
• Post release type (for management reviews)
Each step created of each type incorporates the following:

• Step ID for unique identification
• Step description to appear on the event step header available for multi-language translation
These steps are available at the zone level to be assembled into any number of template dependency
sequences.

Workflow Overview
Steps are created and managed using the System Tailoring Application General business functions|
Workflow orchestration steps menu option.
Before setting up templates it is necessary to ensure that a sufficient number of Final limit check steps
and Synchronisation steps are defined within orchestration steps maintenance so that they can be
added at the relevant points in the template sequence.
Additional Final limit check steps are required when creating rejection sequences back to data
capture. The additional limit check is required where release item data has changed under the
correction, for example if the amount of the transaction or expiry date have been corrected then it will
be necessary to re-check.
Synchronisation steps do no processing but are stage-gate points to ensure multiple steps before
synchronisation finish before steps after can start.
Sequencing Steps into Templates

Each step can be assembled into a template dependency sequence across the three phases.
Data Capture Phase

All log steps must precede the first input type step. The data capture phase can have any of the
following types of step in it:
• Any log step
• Any input step
• Any exchange step
• Any review step
• Any external review step
• Any limit check step
• Any watch list check step
• Any synchronisation step

Workflow Overview
Verification Phase
The verification phase can have any of the following types of step in it:
• Any review step
• Any watch list check step
• Any external review step
• Any synchronisation step
Post Release Phase

The post release phase can have any of the following types of step in it:
• Any print step
• Any post release step
The Final limit check step is already present in a blank or default template. A Final limit check type
step is only mapped where a user has defined a reject step branch and allows key data to be
amended in the data capture step at the head of the reject step branch.
Example Parallel Workflow

Advanced workflow enables the bank to define parallel sequences of steps to allow simultaneous
processing of independent activities. All data capture steps must be ordered in a single sequence but
reviews and external checks can be scheduled in parallel with data capture or in parallel review
sequences. All review activity concludes with a single release step to release SWIFT messages,
postings, documents etc. Subsequent print steps and post release notification steps can also be run
in parallel. See example:
In this example there is an external review step that occurs in parallel to the main workflow. This step
must be completed by the time the authorise step is reached. After release the three post-release
steps can be managed simultaneously.

Workflow Overview
Example Parallel Workflow Utilising Reject Step Branch

Advanced workflow also caters for stand-alone rejection target steps with a separate data capture
through review path to release. In some cases a user may wish to reject back to data capture to make
a small change (such as amending an issue date for a transaction initiated on a previous business
day). In this case after correcting the data, rather than passing again through the standard verification
path(s), only one final review may be required before release. Steps can be tailored using the user
interface (UI) controls to limit the number of fields available for data input, in order to better control
what can be changed and save having to check every piece of data again. See example:
In this example the Issue date step is only reached upon rejection at the Authorise step. A limit check
is optionally carried out (if needed) and then a specific Date set authorisation step is made prior to
release.
The Orchestration templates maintenance allows steps to be:
• linked to others in a series
• linked as a free-standing reject step branch linked as a branching step off another (to create a
section in parallel to existing steps)
• for fast track changes after verification has already commenced.
A graphical diagram viewer is supplied to illustrate the parallel branching and joining relationships.
Reject links (shown with a red flow line in the above example) are defined within the orchestration.

Workflow Overview
Templates are created and managed using the System Tailoring Application General business
functions|Workflow orchestration templates menu option. The following example shows the default
template which can be extended.
Steps can be added in from the available steps list.

See Chapter 3 for an example advanced template.
Each template has an ID and a description. The template contains the step sequences, including
parallel branches and reject step branches.
• The same step can be used in any number of templates, but not twice in the same template.
• The same template can be used in any number of orchestrations.
• Different orchestrations can share the same template but implement different rejection step
targets, different conditions and different SLA step times.

Workflow Overview
• Event orchestrations are created in parameter sets and can be copied and changed in other
parameter sets.
See the Workflow Tailoring User Guide for detailed instructions on setting up and managing
templates.
It is recommended to have a small number of templates to represent two or three major patterns of
work. For example two templates could be established:
Template Name Purpose Steps Included
Major Process To cover events requiring high Log, Input, Limit Check, Watch List
level of user approvals and steps Check, Review, Authorise, Final
e.g. Issuing an LC, Payments, Print
Amendments
Minor Process To cover events requiring minimal Input, Authorise

level of user approvals and steps
or where a high level of straight
through processing with a small
level of user intervention is
possible e.g. Correspondence,
Tracers, Processing a Clean
Payment, Book Off
System Managed Steps

Common steps within the lifecycle of an event do not require user configuration as their behaviour is
managed automatically by the system. Some appear in template definitions to provide fixed reference
points, between which, user-defined steps are mapped (Create, Final limit check, Release,
Complete). System managed steps are assigned to teams and users as are other steps. They are
also included in the dashboard and master browser status selectors and the event step history.
Systems steps comprise the following list:
Creation phase:
• Create – interactively or by batch
• Gateway – created by gateway message
• SWIFT In – created by SWIFT message
Data capture phase:
• Final limit check – where configured and applicable a limit check is triggered at the end of
the data capture phase
Data capture, Verification & Release phases:
• Abort – an action to enable a user to abort a transaction event
Release phase:
• Rate fixing – rates fixed for transactions which are awaiting rate fixing for today
• Fix authorisation– authorisation of FX deal changes
• Release pending – when the release is pending waiting for an end of day cycle to reach start
of business hours for the main banking entity of the behalf of branch
• Release – releasing of documents, postings, messages etc...
Post release phase:
• Complete – final completion of the event

Workflow Overview
Limit Checking Automation

Limit checking can be performed without the bank explicitly configuring a limit check step into a step
dependency sequence template. This is because if limit checking is configured then the step will be
triggered automatically as a system managed step at the end of the data capture phase. If the bank
wishes to request limit checking earlier in the step sequence, a limit check step can be mapped into
the template after a log or input step.
Limit checks are undertaken to perform a limit reservation. After the reservation has been made, at
the next limit check step (or system managed final limit check step) if the customer and amount
details have not changed, the step is not repeated, only if the liability details have changed will the
next limit check perform a reversal and new reservation.
The final limit check at the end of the data capture phase is the minimum requirement to achieve the
correct reservation; this is automated in the system. This saves the bank implementing new templates
to achieve basic limit checking.
The system option ‘AlwaysApprove’ will cause all limit check steps to be undertaken and be assigned
to the team and or user for approval.
Rejection step branch lines, include steps for use uniquely triggered by a rejection back in to data
capture. These lines can include a limit check or user defined Final limit check step to re-reserve
against changed data.
Configuring Orchestrations
Workflow orchestrations are held within parameter sets using the parameter set type of
Orchestrations. The default orchestrations parameter set is mapped to the top of the branch
hierarchies and contains orchestration details for each event used in the zone. This provides the
default workflow for the system.
All workflow orchestrations must be defined within a parameter set. Each must be for a single product
and event and use a single template. A separate workflow orchestration exists for each event for each
product in the default orchestration.
Each orchestration is provided as live - status ‘in-use’. To change details of an orchestration create a
not in-use copy, where details can be amended. When the bank wishes to make these changes live,
the amended orchestration is made in-use, overriding the main details. From that moment all new
events created follow the new orchestration details. Existing transactions continue with the previous
orchestration details.

Workflow Overview
See the Workflow Tailoring User Guide – FusionBanking Trade Innovation for detailed instructions on
setting up and managing workflow orchestrations.
Orchestrations under Advanced Workflow

Orchestration details are configured within parameter sets at the overall level or the step level.
Overall Orchestration Parameters

Bank defined step sequence templates can be utilised. Attributes are available from the steps defined
in the associated template.
Initial steps -the first step to start from when event is created interactively, from batch, from the
gateway or via SWIFT.
‘If validation fails initiating from…’ steps– Events created via SWIFT, Batch and Gateway action
may fail in the initial step (as defined in the SWIFT, Batch or Gateway Initial step). In this case, the
reject to step must be defined. The system will perform it automatically if an error is encountered in
the initial step. The point to continue after failure must be either an input or log step.
If the initial step is a log of input step then the validation failure step can be the same step.
Verification release failure step - If a user completes a review type step and release is the next
step, any errors/warnings encountered in the release step will handled by the system transferring
back to same review step. If however there were intervening non review steps, it cannot transfer back
to a previous completed review step. Instead the ‘If release failure after processing’ step is initiated in
the master browser/dashboard to continue.

Workflow Overview
Step Attributes
Average step times – this is configured for each individual step, the SLA details track the actual time
taken under the step against the average defined.
Step conditions -whether the step is undertaken always, under a condition, or never which
effectively removes the step from the sequence. For an example of criteria, a criterion can be used for
adding an extra review step for amounts over a certain threshold.
Reject to steps -for any template step which allows rejection, the point to continue after rejection is
defined; to either an input or log step.
Release item validation –by default back office validation of release items occurs in the last input or
exchange step, at release and the last input or exchange step in rejection flows. This input allows the
bank to configure any input, exchange or review type step to undertake validation where required.
Step attributes are defined for all the steps defined in the associated template. The following example
includes a template with multiple log, input and review/verification steps.
The following example shows the default template which can be extended:
Attributes can be set for the step configured in the template.

See Chapter 3 for an example of advanced orchestration.
It is recommended that the bank ascertains the parts of the business which require an advanced
workflow and that a new Orchestrations parameter set is mapped to the required branch banking
entity. This allows the default parameter set to remain as the standard in all other areas of the
business in the zone if required.
New Orchestrations parameter sets contain no orchestrations initially. Required event orchestrations
can be copied from existing parameter sets, or a new one can be created. The template can be
changed and the new orchestration and step level details set.

Workflow Overview
See the Workflow Tailoring User Guide – FusionBanking Trade Innovation and the System Tailoring
User Guide – FusionBanking Trade Innovation for detailed instructions on setting up parameter sets
and mapping them to branches.
Exchange Steps
Exchange steps are allowed within the logging or input steps (data capture phase) for event data to
be provided from an external system (data enrichment). Required event fields are passed to an
external system via the gateway; that system can then populate or confirm that data as required and
pass back into the step. Normal validation applies. If required the user can repair the data returned
correcting for warnings and errors. Warnings, errors, gateway action items and documents can also
be returned from the external system.
See chapter 5 for details on configuring and executing exchange steps.
External Review Steps

External review steps retrieve request response data from an external system. Event data can be sent
as part of a request query (e.g. party details for a signature check). Step level customisation enables
the bank to create custom fields to store the response which is held within the step. An external
system response can complete the step automatically or require user review/approval. Responses
and review/approval narratives are retained against the step history. Warnings, errors and gateway
action items can also be returned from the external system.
See chapter 5 for details on configuring and executing external review steps.
Configuring Fields Available in Log or Input Steps

The system allows all input step fields to be included in log steps. Some products by default include a
standard sub-set of fields available in the default log step.
The system is provided with a pre-delivered set of user interface (UI) control files for the default log
step for each event.
Both standard and advanced workflow allows the fields displayed within log and input steps to be
tailored individually allowing full flexibility in the details presented. This is configured separately for
each event. Each file is delivered with the following:
• A visibility attribute for all fields available as at the input step. The bank can set each field
attribute to either “true” or “false” to configure the log or input step fields available as required.
• A read only attribute for all fields available as at the input step. The bank can set each field
attribute to either “true” or “false” to configure the additional log or input step fields which are
display only as required.
• Settings to allow sections of the input screen to be collapsed on initial entry.

Workflow Overview
The following example shows the standard ILC issue short form log step with additional collapsed
shipment details. Clicking the ‘+’ sign against the Shipment heading opens the section for data input.
The UI control show/hide, read only and pre-collapse facility is also available for input steps but care
must be taken not to hide a field required for input validation.
See the SDK Screen Tailoring Guide – FusionBanking Trade Innovation for detailed instructions on
how to configure each log step.
The Dashboard and Master Browser

The dashboard is the focus for the majority of users as it shows a prioritised list of event steps in
progress for the user or the team they are currently working in. From the dashboard the user can
select and open event steps to continue work on.
The master browser enables a user to enquire on the full history of completed transaction events and
the step statuses of events in progress.
Step related information for events is presented in different ways according to context:
• The Dashboard overall totals pie chart is categorised by step phase to aggregate the
individual steps – where under parallelism an event has steps capable of running across both
data capture and verification phases, the step is categorised within data capture.
• Dashboard Overall totals and Team and User totals include all active steps for events in the
count.
Utilising the step type allows for all review step types or watch list check step types to be selected,
even though they may be situated in the workflows in different phases.

Workflow Overview
See Chapter 6 for full details of workflow functionality available within the dashboard.
See the SLA Dashboard User Guide – FusionBanking Trade Innovation for details on using the
dashboard.
Watch List Checking

Watch list checking is permitted in both the data capture and verification phases. Only one check can
be undertaken in one orchestration, using one watch list checker document. However the same check
can be repeated in a single orchestration by defining separate check step IDs. The history of watch
list checking activity is available against the step. The watch list status data is only available as at the
latest status.
A watch list check step cannot run in parallel with another watch list check step. Watch list check
steps can be configured in parallel in templates as conditions or internal processes may be used to
ensure separate running. If a watch list check step is requested while another is running, the check is
not executed/bypassed.
See chapter 5 for details on configuring and executing watch list check steps.
Populating an External Dashboard

Under advanced workflow data items currently available in the Dashboard work in progress list are
available to be sent as messages to an external system for a dashboard to be monitored there.
This can be useful where some bank users want an overall view of the service being offered to the
customers they are responsible for. This feature allows up to the minute status tracking of in flight
transactions.
Data for all step transitions which involve user interaction are made available in a queue for a
subscribing system or published as a topic for access from multiple systems. The data published is for
all events in a zone. The subscribing system can filter for specific products as required.
All the event data to be presented on the external dashboard is recorded and published every time
one for the following step actions occurs:
• When the step is assigned
• When the step is pended
• When the step is completed
• When the step is rejected
• When the step is aborted
The following details are provided:

• Product – Long name
• Product – Short name
• Event – Long name
• Event – Short name
• Created by (via) – Manual, Gateway, SWIFT, Batch
• TI Event reference
• TI Event step description reference
• Applicant reference

Workflow Overview
• Customer – Principal party

• Customer Name and Address
• Amount & Currency – original formatted amount
• Team
• User
• Status
• Step ID
• Step description
• Deadline timestamp
• SLA type
The transitions are sent in messages as soon as the changes are committed to the database. Multiple
messages are sent when there is more than one transition before the event is pending the next user
action. Uncommitted changes are not sent. Notifications can be configured to be published to general
topics available to multiple subscribers or to individual subscriber queues.
See the System Interfacing Guide – FusionBanking Trade Innovation for instructions on how to
configure the publishing and subscription parameters.
Populating a Dashboard from External Data

Under advanced workflow the facility exists to define a Zone as a proxy of an external transaction
database. This enables the external system data to be presented on the cross-zone dashboard under
the proxy zone. Navigation is also possible from the dashboard WIP and diary items to drill into the
underlying data in the external system.
Example scenarios which could utilise this capability are as follows:
• Access live transaction information from another system – a strategy for implementing the
system would be to only add new transactions, allowing exiting transactions to be maintained
and completed in the legacy systems – this facility would provide a combined view of
outstanding transactions during that transition period.
• Access historical data – another strategy is to take-on transactions in flight, but this would not
consist of the full transaction history – so this can provide access to historical data.
The expectation is that a Zone Proxy provides access to this legacy data.
See the SDK Systems Integration Guide – FusionBanking Trade Innovation for instructions on how to
configure the cross zone dashboard and cross zone navigation.
Accessing a Master or Event Step from an External System

Under advanced workflow banks can configure from external applications to directly access the
system masters and events from outside of the application. Where authorised within a common
authentication facility, the user is transferred into the zone of the master or event. Based on the
parameters passed, the page opened will either be the master summary page or the event page. If
there is a problem with the data, an error will be shown with a button to enable the return to the
external application. The master summary page will have a menu option of Return rather than Close,
which will return to the external application using the source URL.
configure the navigation.

Workflow Overview
Accessing an External System from the Application List

Under advanced workflow banks can configure for users to be able to work in the system, but from
there to be able to access alternate applications to perform self-contained tasks. Entries can be
added to the user’s application list representing those applications. These entries are granted to
teams of users using capabilities. Both the system and the external application should be controlled
by a common authentication facility. Separately implemented, the external application should have a
similar feature of navigating back into the system when the user has finished work there.
configure the external applications.

Implementing Advanced Workflow Orchestrations

This chapter explains how the pre-delivered orchestration is structured and how settings can be
configured according to the bank’s requirements. Under advanced workflow this chapter explains how
to create new step sequences, store them in templates and incorporate them into orchestrations
within parameter sets.
The following introduces the default orchestration configuration. Advanced workflow permits changes
to the default configuration or the set up of new configurations.
The Default Steps

The following steps are pre-delivered by Misys. These are required to undertake the default workflow.
Steps cannot be created, changed or deleted under standard workflow:
Step ID Step Description Step Type Notes
Start System
Log Log step Log
Limit chk Limit check Limit check
Input Input step Input
Final limit chk Final limit check Final limit check Uses a separate default
SLA average step time to
Limit check
Watch list chk Watch list check Watch list check
Review Review step Review Defined as a standard

review step
Authorise Authorise step Review Defined as a final review

step – uses a separate
default SLA average step
time to Review
Release System
Final print Final print step Print
Complete System
System managed steps are not maintained by the user but provide reference points to map steps
between.

The Default Template

The following template is pre-delivered. Templates cannot be created, changed or deleted under
standard workflow:
Template ID DEFAULT TEMPLATE
Template Description Default template
This template links all steps in single sequence. Parallel lines can be added to this sequence.
Step Phase Links to Step
Start Start of Data capture Log
Log – Log step Data capture Limit chk
Limit chk – Limit check Data capture Input
Input – Input step Data capture Final limit chk
Final limit chk – Final limit check End of Data Capture Watch list chk
Watch list chk – Watch list check Verification Review
Review – Review step Verification Authorise
Authorise – Authorise step Verification Release
Release End of Verification Final print
Final print – Final print step Post release Complete
Complete End of Post release
The step conditions, rejection targets and SLA information are managed separately within the
orchestration definitions.
The Default Orchestrations Parameter Set

The default parameter set is pre-delivered. Orchestrations parameter sets can be created, changed or
deleted and mapped to branches.
Parameter Set ID DEFAULT-Orchestrations
Parameter set Description Default Orchestrations parameter set
Parameter set Type Orchestrations
The default parameter set contains a full orchestration for each event used within the zone.
As part of the implementation the default orchestrations parameter set is mapped to the top branch or
branches in the zone hierarchy.

The Default Workflow Orchestrations

A separate workflow orchestration exists for each event. All orchestrations share the default template,
but steps are conditioned according to the characteristics of the event. For example correspondence
events do not require limit checks or watch list checks so for these events the step condition is set to
‘never’. These steps are not undertaken and are not presented on the step history or the SLA step
times.
Additional default conditions are determined by system option settings at implementation. If a bank is
not using watch list checking or limit checking, then under implementation these steps are set to
never in all event orchestrations.
Not all events ‘join in’ to the template step sequence at the same point. Many creation events include
the log step. Maintenance action begins at the input step. Some SWIFT or gateway originated events
begin at the authorise (final review) or system managed release step. These events still use the
default template as all events could be rejected and so resume from the input step, requiring the
intervening steps. All steps remain available in case a bank does wish to modify a workflow to include
any step.
Where the branch is configured for release item validation, by default release items are verified
against the back office at the release step and the last data capture phase input or exchange step.
This includes the data capture phase in rejection flows.
Under advanced workflow, orchestrations can be changed, deleted or created using new templates
and new steps.
Configuring Orchestrations and Parameter Set Conditions

under Advanced Workflow
New steps incorporated into new templates allow complete flexibility of orchestrations effective for
business entities throughout the zone. See chapter 4 for details of maintaining orchestration
parameter sets.
Maintaining and Creating New Steps

When defining new steps, note that the step ID is the unique 15 alphanumeric character identifier and
the description is the 35 alphanumeric character narrative text, which is translatable under the multi-
language capabilities. The following lists where the ID and descriptions are presented within the
system.
The following show the ‘Step Description’ within the context of the transaction event:
• Transaction event header
• Step history
• SLA step times

The following show the ‘Step ID’ and the ‘Step Description’ (concatenated with a hyphen):
• Workflow steps maintenance
• Workflow templates maintenance
• Workflow orchestration maintenance
• Event / Team mapping
• Security User Roles maintenance
• Dashboard WIP list selection filter
• Master browser WIP list selection filter
• What can I do? – allowed steps

The following show the ‘Step ID’ where space is at a premium:

• Dashboard tables
• Dashboard WIP list
• Master browser WIP list
Maintaining Templates Available to Orchestrations

The templates maintenance allows steps to be linked using a list structure which allows:
• Using the Add button, steps to be added between two already linked steps. (Add B in-
between A and C will create a sequence of A then B then C).
• Using the Add branch button, steps to be branched off another. Where A is followed by C as
above: (Branching B off A will cause A to be the head of a parallel line beginning with C and a
parallel line beginning with B).
• Using the Add reject branch button, steps to be the head of a new reject correction sub-
workflow – this will start with a data capture step and should include a Final limit check step
for the reject branch.
Steps can be added from the available steps selector below:

Other standards for the templates maintenance are as follows:

• Data capture steps (types Log, Input and Exchange) can only be mapped in the main line;
these cannot be mapped in branches.
• Steps can be moved above or below other steps but only within a main or parallel sequence.
Steps cannot swap with others which have more than just one link below and one above.
• When adding a branch to a step in the data capture phase, the join in step is defaulted to
release (it can then be changed by the user).
• When adding a branch to a step in the verification phase, the join in step is defaulted to
release (it can then be changed by the user).
• When adding a branch to a step in the post release phase, the join in step is defaulted to
complete (it can then be changed by the user).
• Steps can be added under branched steps as non branch steps.
• When adding a reject step branch a data capture step must be selected. It is recommended to
add a final limit check and authorise step after data capture.
• Synchronisation steps can be added between two existing steps. Initially creating a single link
above and below:
• A step branch can be initiated above, then after intervening steps are added its join in
step can be moved to the synchronisation step.
• A step branch can be initiated from the synchronisation step.
• More step branches can be added to the synchronisation step as required.
• The synchronisation point is now complete ensuring all steps linked above it will complete
before those below can start.
See the following example as an illustration of step sequences with links:
The indented steps indicate branches from the main line steps. The template map can be shown
expanded or collapsed and individual step collections can be expanded using the + icon or collapsed
using the – icon.

Press View diagram to see the same details in graphical form.
The diagram is available under modern versions of browsers. Please refer to the Technical Release
Notes for the latest list of supported browser versions.
Defaulting & Maintaining SLA Step Times

The overall default step level processing times are held in the orchestrations parameter sets where
steps are managed. Event level SLA details for completion times by service level type are held in the
SLA details parameter sets. This allows for the following to be provided per parameter set:
• At SLA level the escalation times for each type of SLA and each event (the RAG criteria).
• Overall default average times for step types for all products and events.
• Step category average times for each event (defaulted from the overall).
• Step average times for each orchestrated step (defaulted from the step category times).

Within the workflow orchestration held in the orchestrations parameter set, the step category times
are pre-populated into the actual steps defined by the orchestration template. The following example
is using the default template:
Step Category Average Times per
Step Type Steps in the Default Template
Event under Workflow Orchestration
Log Log steps Log - Log step
Limit check Limit check – post log steps Limit chk - Limit check
Input Input steps Input - Input step
Limit check & Limit check – post input steps Final limit chk - Final limit check
Final limit check
Exchange Exchange steps N/A
External review External review steps N/A
Watch list check Watch list check steps Watch list chk - Watch list check
Review Review steps Review - Review step
Review Final review steps Authorise – Authorise step
Rate fixing Rate fix steps Not present in template
Fix authorisation Rate fix authorisation steps Not present in template
Print Print steps Final print – Final print step
Under advanced workflow, where multiple steps of each type can be placed in a sequence, the
category time is applied to each step of that category. For example; if the step category time for log
steps is 10 minutes and the template includes two log steps, each step has a step time defaulted to
10 minutes, 20 in total.
Where steps are configured in parallel lines two sets of remaining times are maintained:
• Total remaining processing step activity: All remaining step time for the current and all future
steps.
• Total remaining processing time: The remaining step time of the longest parallel path through
to completion of the event.
See Chapter 6 on Monitoring SLA Step Times for more details.
Defaulting & Maintaining Orchestration Parameters

For each orchestration the following details are defaulted and configured as follows:
• Configuring orchestration level parameters:
• Configuring initial steps. The first step to start from. For interactively created events the
default is the first log step. For the others, from batch, from the gateway or via a SWIFT
message the default is the first input step. To change, a dropdown shows the full list of
valid steps available.
• Configuring reject to steps from the system release step. Transactions initiated from
SWIFT or the gateway may start from the release step but encounter an error. The

rejection is undertaken automatically by the system. Here the reject to step (where
rejected to from release step) is defined for each form of event initiation. It is defaulted to
the last input step. To change, a dropdown shows the full list of valid steps available.
• Configuring step level parameters:
• Configuring SLA step times – the defaulting is described in detail in the previous section.
The prefilled default for each individual step can be adjusted to the average time required.
• Configuring step conditions – whether the step is always executed, never executed or
executed if conditions are met. For a new orchestration this is initially defaulted to always.
• Configuring reject-to steps for each template step which allows rejection – for each step
where rejection is allowed the target step (where rejected to) is defined. For a new
orchestration this is initially defaulted to the last input step. To change, a dropdown shows
the full list of valid steps available.
• Reject to steps are the mandatory step a rejection passes the event back to. If the user
has the capability ‘OrchestrationAllowRejectSelect’ then the reject step is the default but
the user can select any other applicable step prior to the current one to reject to.
• Release item validation – by default the last input or exchange step is set for release item
validation; also the last input or exchange step in rejection lines defined. (Release item
validation is undertaken automatically at the release step).
See Chapter 4 for inter-relation considerations between the above parameters.
Setting up Step User Roles

The mechanism for assigning users to teams, roles to teams and then confirming which users have
which team roles is described in the Global Processing Implementation Guide – FusionBanking Trade
Innovation. The key characteristic for standard and advanced workflow is that individual steps such as
(Log step, Log1, Log2, Input step, Input1, Input2 etc...) are mapped to roles. For defining roles for
provisional events, a provisional instance of each step is listed to be mapped separately where
required.

The step ID and description are shown for easy identification; however similar step references may be
hard to distinguish between. To ensure the user is selecting the appropriate steps, a ‘Where used’
function is provided to identify the required step.
This function shows in which templates, event orchestrations and parameter sets the step is currently
defined. Not in-use orchestrations can be included or excluded from the search. This assists security
administrators in matching the user roles in conjunction with the required orchestration parameter
sets.
The ‘Where used’ function is available within the Security | User roles maintenance and the System
tailoring | Event/Team mapping against a selected step.
See the Appendix A for a worked example of setting up teams, users and roles with orchestrated
steps.

Configuring Workflow Orchestration

This chapter covers the parameter set settings available to support workflow orchestration. It includes
the system options which affect the initialisation and behaviour of configurable steps.
Orchestration Parameter Sets

A default orchestration parameter set is provided at the top of all branch hierarchies within the zone.
This set includes an in-use orchestration for all products licensed in the zone.
These orchestrations cannot be changed directly, but can be updated by editing a not in-use copy and
making that copy in-use.
At lower points in the branch entity hierarchy new orchestration parameter sets can be mapped. The
bank can then copy in or create new event orchestrations as required.
To identify the workflow applicable to a transaction branch the following checks are undertaken:
• Is there an Orchestrations parameter set linked to the transaction behalf of branch? If so
check for an in use orchestration for the product and event. Use this if found.
• Else look up the branch hierarchy until another Orchestrations parameter set is found. Then
check for an in use orchestration for the product and event. Use this if found.
• Continue on up the branch hierarchy. There will be the Default Orchestrations parameter set
linked to the head branch(es) across the zone. There is an in use orchestration for all
products and events used.
If no parameter set is found the user cannot create this event.
Based-on Orchestrations parameter sets can be used for tree-view type sub-categorisation only.
There is no overriding of the contents of one orchestration in it’s based on child orchestration in this
case. For example, if you wish to have a small condition variation for an ILC issue event in a lower
branch, it is necessary to create the whole ILC issue orchestration in a separate parameter set and
map it to the required branch.

See the Global Processing Implementation Guide – FusionBanking Trade Innovation for general
information on setting up parameter sets.
The following example shows a not in-use instance, ready to be confirmed in use that will become the
new live version:
NB: child parameter set ‘in-use’ orchestrations can be deleted. After deletion, the parent or main
default parameter set in-use orchestration will apply.
A standard implementation would be that there is a standard in-use orchestration for all products in
the default parameter set. A separate parameter set can be defined to control business within a
certain banking entity. Within that entity only the events which require special workflows are defined.
Only for those events undertaken in branches within that entity is the special workflow in force.
In the following illustration there are two banking group’s hierarchies. The default parameter set is
mapped to both. All events are represented in the default set. For branches under the entity MBWW
an orchestrations parameter set is defined with an advanced workflow orchestration for ILC issue
events.
For ILCs issued in branches within this entity the separate sequence of multiple log and review steps
is followed.
See the System Tailoring User Guide – FusionBanking Trade Innovation for instructions on setting up
parameter sets and mapping them to branches.

Orchestration Setting Options

For each orchestration the following settings can be configured. These are considered in detail in the
following sections:
• Configuring Initial Steps, Reject-to Steps and Step Conditions
• Configuring SLA Step Times
• Handling of Steps with Conditions
• Configuring Release Item Validation
Configuring Initial Steps & Reject-to Steps

Different events may require different starting points and reject-to points for the same step sequence
template. For example an ILC issue manually entered could start from a log step. The same event
entered from batch, gateway or SWIFT channel may not require logging and start from an input step
instead. Book off events could start from the final review step or the release step. All rejected steps
must reject to a data capture step. Normally this would be the final input step to allow data correction
and to continue through the step sequence from that point.
This example illustrates for an orchestration step sequence the relationship between initial steps, step
conditions and reject-to steps. First we consider a template sequence:
The template includes 13 mapped steps. The orange steps are generated by the system (the release
phase is a system generated phase). The dark and light blue shading is to illustrate that verification
phase steps can also be mapped in the data capture phase. Brown represents post release steps.
Initial steps can be any of the steps on the middle line in the diagram (log, input, review or release
steps). Reject to steps can be any log or input type step (dark blue middle line steps).
A key to the individual steps is as follows:
Step Description Possible Initial Step Possible Reject-to Step
Initial log
Detailed log
External review
Input
Watch list check

Step Description Possible Initial Step Possible Reject-to Step
Limit check
Exchange
Final limit check
Review 1
Review 2
Authorise
Release
Final print
Post release 1
Post release 2
The next illustration shows an example set of initial steps. A data take-on event gateway message
could begin at a log step, input step, review step or the release step.
For steps which permit rejection, the reject to step can be any data capture log or input step. Normally
the final input step or final log step is chosen as only one user action is required to rectify any issues
found.

Configuring Step Conditions

By default, all steps are condition Always. However you may wish to do a certain review step under a
certain criterion; only if the amount is above a certain level.
• A step with a condition of Always is always executed.
• A step with condition of Never is never executed (unless it is rejected back to, then it is
executed unconditionally).
• A step with a condition of Criteria is executed if the criteria are met (unless it is rejected back
to, then it is executed unconditionally).
• A step can be conditioned on any number of criteria based on the event fields available.
In the following example Review 2 occurs conditionally:
Any available event field can be used to construct one or more criteria.
Configuring Exception Processing

In the same example above Input 2 occurs as Never.
A step set to criteria Never is not included in the event normally, but if it is the target of a reject step
then it will be executed. When using a reject step branch there is no need to make the first step
Never. The first step in a reject step branch will be executed unconditionally.
The Impact of Conditions on Processing Flow

The impact of conditions (Always, Criteria or Never) on the process flow is as follows:
• Initial steps: In the illustration the choice is made between the log 1, log 2, input 1 or input 2
steps. Step conditions apply here. If the initial step selected is conditioned as ‘Never’ the
event proceeds to the next step in the sequence.
• Reject-to steps: these tell the system where to go on a rejection action by the user or the
system. In these cases the conditions DO NOT apply. If a reject to step is Never or some
criteria which are not met, then the step is still undertaken when specified as the rejection
point from a review step. From the next step on going forwards conditions apply as normal.

• Step conditions: conditions do not apply under rejection. If they did, spurious scenarios are
possible where there is no available reject-to target step. This also allows a step to be
reserved to be undertaken only under a rejection for exception processing.
Configuring SLA Step Times

Refer to the Workflow Tailoring User Guide – FusionBanking Trade Innovation for instructions on
configuring average step times. The defaults are set up per parameter set.
There are three levels available for setting the step times and the lower level times used default from
a higher level:
Level Where Set Defaulted From
Overall Defaults Orchestration selection

screen – Step category
times – Overall Defaults
button
Event Step Category Orchestration selection Overall Defaults

screen – Step category
times button
Orchestration Step Orchestration Event Step Category

New/Update screen -
Assign step attributes
button then Assign step
time button
For example the generic overall defaults have 3 minutes as the default for log steps.
On the creation of the first orchestration for an event, the event step category times are defaulted.
These can be edited prior to completing the orchestration so that these defaults apply.
Default log step time for Import Guarantee Issue events is changed to 4 minutes.

Where there are multiple input steps in the orchestration template, all log steps are defaulted to 4
minutes.

Individual step average times can then be adjusted using the Update button.
The times for all individual steps can be adjusted as required or left using the step category default.
Note: Print steps are included under SLA step times but post release type management review steps
are not included. These steps are for oversight of already completed events so they fall outside any
SLA agreement with the customer.
Viewing Progress against SLA Times

From each event it is possible to view the Service Level Details showing the time taken against the
average step times indicating where any are overdue.
Handling of Steps with Conditions
Running of a conditional step is dependent on the criteria results at the time the step is reached. In
the following example if the user enters a transaction for 10,000.00 USD. At the detailed log step the
Verification 2 step is projected as not applicable to the SLA step times as it fails the criteria as the
amount is not greater than 10,000 USD.

On continuation when the step Verification 2 is reached the step line for it is removed from the
display.
However if subsequent to logging, details are changed during input, (amount = 12,000.00 USD) the
criteria are now met and the step status is changed from ‘Not required’ to ‘Not started’.
The SLA time is now included for Verification 2.
Configuring Release Item Validation

All steps of type Input, Exchange or Review can be configured to validate the release items against
the back office system by setting the Release item validation tick-box.
The Major processing option ‘ReleaseItemValidation’ must also be enabled for the entity of the
transaction behalf of branch for the release item validation API to be called.

Additional Workflow Orchestration Step Interaction

This chapter covers the supporting options for workflow orchestration. The relationship between
workflow and provisional events and subsidiary events is also explained.
Configuring Limit Checking/Reservation

Limit check steps, can follow a log step, input step or can be a system initiated final limit check. The
system initiated case acts as a default if your bank has indicated limit checking/reservation is required
and no specific limit check steps have been mapped. This system step always occurs right after the
final data capture phase step. It is invoked:
• If no prior limit check has been carried out i.e. the limit check step was not configured as an
earlier check
• Where an amount, date or party or other criteria that might affect limits has changed since the
last reservation was made. This would require the previous reservation to be cancelled and a
new one requested
A limit check step is actually a request for a limit reservation. Once a check has been completed
utilisation is reserved from the amount and currency of the transaction.
A rejection step branch can include limit check steps to cater for where date, parties or other criteria
have affected the limits.
Options Controlling Limit Checking/Reservation

Option Where Set Description
AlwaysApprove Branch options: Limits If it is ‘No’ then the step is referred to a user for approval
Service option only if the limit checked for is exceeded.
If it is ‘Yes’ then the step is referred to a user irrespective
of the response of the check or if a check was made.
CheckLimits Branch options: Trade This controls checking the Departmental Limits
Finance option application.
Note – this is only available where there is one MBE in a
zone.
CheckML Branch options: Trade This controls checking external limits, enabling a user to
Finance option link to a facility.
LimitCheckMMDeals Branch options: Limits This controls limit reservations for Money Market deals.
Service option
Within the step history details of the execution of each step are shown. For limit checking the step
status history shows the system generated check request(s) and also any user approval if required
due to a limit exception or always approve enabled. The specific check type is included in the step
status history.

Step Completing without Re-reservation Required

Started Last Action Time Step Status Assigned Team/User Step Action
6/14/13. 6/14/13... 2s Limit check Initiated ** System **

.
6/14/13. 6/14/13... 0s Limit check Completed ** System ** None required

.
Check Completing without User Approval

6/14/13 6/14/13... 2s Limit check Initiated ** System **

..
6/14/13 6/14/13... 3s Limit check Requested ** System ** Facility service

..
6/14/13 6/14/13... 0s Limit check Completed ** System **

..
Check Requiring User Approval

6/14/13... 6/14/13... 2s Limit Initiated ** System **

check
6/14/13... 6/14/13... 4s Limit Requested ** System ** Departmental

check limits
6/14/13... 6/14/13... 0s Limit Assigned ATEAM/SUPERVISOR

check
6/14/13... 6/14/13... 2m Limit Completed ATEAM/SUPERVISOR Overridden

check
See Chapter 6 for full details on the step history and the step status history.
Configuring Watch List Checking

The following options and inputs control watch list checking:
Zone general option – WatchListChecking. This controls the availability of configuring watch list check
type documents. It is not used in controlling watch list checking steps.
Within System tailoring | Watch list checker definition, watch list check messages can be defined for
events or parties.

Within System tailoring | Product / event level documents the outward XML message details are
defined as an output document.
If no watch list check document is set up for the product and event, the following system warning is
presented after the previous step completes – as the WLC step is being initiated.
No data has been sent out, the watch list check step should be opened, rejected and the document
details adding for the event to send out the request.
If no document is set in System Tailoring application’s General Business Functions|Watch list checker
definition for the product and event, checking is deemed to not be required for this event, the step is
bypassed / not actioned. This allows the same template to be used across contexts where checking
may or may not apply.
Where details are fully set up, the gateway message is sent. The step status is set to Requested. The
step is assigned to the appropriate team/user using the round robin rules. Normally the step is
completed automatically on receipt of the response message. If the step requires user intervention it
is already assigned to a team and/or user. The gateway response message used is TFWLCRSP.

When the time for the step to be executed arrives:

• If under a parallel workflow, a watch list check step is requested while another watch list
check is underway the second check is not executed.
See the System Tailoring User Guide – FusionBanking Trade Innovation for details on setting up
gateway documents for watch list checks.
Watch List Checking Step Execution

Prior to a response being received if the user opens the event step, there is a warning that the
response has not yet been received.
The gateway message viewer includes previous messages for this event. The Gateway event
creation message in this case.

The user can optionally override the warning.

After a response is received (with a fail condition) the following is displayed.
Within the step history details of the execution of each step are shown. For watch list checking the
step status history shows both the system generated check request and either the completion by reply
message or manual completion by a user.
Check without User Interaction

6/14/13.. 6/14/13... 1s Watch list Initiated ** System **

check
6/14/13.. 6/14/13... 1s Watch list Requested ** System ** Check requested

check
6/14/13.. 6/14/13... 1s Watch list Completed ** System **

check

Check Followed by User Override

6/14/13.. 6/14/13... 1s Watch list Initiated ** System **

check
6/14/13.. 6/14/13... 1s Watch list Requested ** System ** Check requested

check
6/14/13.. 6/14/13... 1s Watch list Assigned ATEAM/SUPERVISOR

check
6/14/13.. 6/14/13... 10s Watch list Completed ATEAM/SUPERVISOR Matches

check overridden
The step history View function can show watch list check step response details at any time.

Configuring External Review Steps

In order to create and use an external review step several set up procedures are required:
• Create customised fields – step level custom fields are required to store the response
returned from the external system
• Step level document template - a gateway template is required to define the data to send to
the external system for review, including any customised fields
Step Response Field Customisation Setup

Within step level customisation the customised fields to hold the data returned are defined.
In the following example an external review step with a Step ID of EXRV has two fields defined
SEF1_Name and SEF2_Name.
The external review step ID must be upper case without embedded blanks to be compatible with the
associated step level customisation.

Once defined and deployed in customisation, the field tags are included in the extra data of the
deferred response. When viewing the details within the external review step this will include
information on the two extra fields defined.
See the SDK Common Facilities Guide – FusionBanking Trade Innovation for details on the tools
which support customisation.
See the SDK Application Extension Guide – FusionBanking Trade Innovation for details on the tools
which support customisation.

Step Document Setup

Within System tailoring | Step level documents the outward XML message details are defined as an
output document. This holds the event fields and event level customised fields to be sent to the
external system as context information for the response. This data is not returned/updated back in the
system. The response is retained against the step within customisation.
Within step level documents the supporting event data to pass to the external system is defined. The
event fields for the defined custom fields can be included in the document template.

If no document is set up for the external review step the following error is presented:
Where details are fully set up, the gateway message is sent. The step status is set to Requested. The
step is assigned to the appropriate team/user using the round robin rules. Normally the step is
completed automatically on receipt of the response message. If the step requires user intervention it
is already assigned to a team and/or user.
The gateway response message used to send the response back to the system is TFEXRRSP.
See the Workflow Tailoring User Guide – FusionBanking Trade Innovation for details on setting up
external system links and the gateway documents for external review steps.
See the Systems Interfacing Guide – FusionBanking Trade Innovation for details on using the
deferred response mechanism.
External Review Step Execution

The gateway message viewer includes previous messages for this event. Gateway creation, watch list
check and an exchange message in this case.

The user can optionally override the warning.

When the response is received:
• The TFEXRRSP message format includes an auto-complete flag. Provided that there are no
errors, warnings or gateway action items, then the step is completed automatically if this flag
is set. If the step cannot auto-complete or the flag is not set then user intervention is required.
The XML message is returned within a deferred response message wrapper. The deferred response
can return errors and, warnings to apply to the step.
Example External Review Deferred Response Message

<?xml version="1.0" encoding="UTF-8"?>
<DeferredResponse xmlns="urn:control.services.tiplus2.misys.com"
xmlns:c="urn:common.service.ti.apps.tiplus2.misys.com"
xmlns:m="urn:messages.service.ti.apps.tiplus2.misys.com"
xmlns:n="urn:custom.service.ti.apps.tiplus2.misys.com"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<DeferredHeader>
<Service>TI</Service>
<Operation>TFEXRRSP</Operation>
<Credentials>
<Name>Name</Name>
<Password>Password</Password>
<Certificate>Certificate</Certificate>
<Digest>Digest</Digest>
</Credentials>
<ReplyFormat>FULL</ReplyFormat>
<ReplyTarget/>
<Status>SUCCEEDED</Status>
<Details>
<Warning>Verification reverification override</Warning>
<Info>Information reverification repeat text</Info>
</Details>
<TargetSystem>ZONE1</TargetSystem>
<CorrelationId>74243</CorrelationId>
<TransactionControl>NONE</TransactionControl>
</DeferredHeader>
<m:TFEXRRSP>
<m:Context>
<c:Branch>KBSL</c:Branch>
<c:Customer>ABC</c:Customer>

<c:Product>ILC</c:Product>
<c:Event>ISI</c:Event>
<c:OurReference>ILC00001209BWW</c:OurReference>
<c:Team>BLYTHA</c:Team>
<c:BehalfOfBranch>KBSL</c:BehalfOfBranch>
<c:EventReference>ISS001</c:EventReference>
<c:Step>EXRV</c:Step>
</m:Context>
<m:ExtraData>
<n:SEF1_Name>Successful</n:SEF1_Name>
<n:SEF2_Name>Successful</n:SEF2_Name>
</m:ExtraData>
</m:TFEXRRSP>
</DeferredResponse>
Error and Warning Responses

• An error returned cannot be overridden in the system, the step must be rejected.
• A warning returned can be overridden in the system as any system generated validation
warning.
See the Systems Interfacing Guide – FusionBanking Trade Innovation for configuring request and
response messaging.
After a response is received (with a fail condition) the following is displayed.

Within the step history details of the execution of each step are shown. For external review steps the
step status history shows both the system generated check request and either the completion by reply
message or manual completion by a user. The User action selected is included in the status history in
the Step action column.
Check without User Interaction

6/14/13.. 6/14/13... 1s External Initiated ** System **

review
6/14/13.. 6/14/13... 1s External Requested ** System ** Check

review requested
6/14/13.. 6/14/13... 1s External Completed ** System **

review
6/14/13.. 6/14/13... 1s External Completed ** System **

review

Check followed by User Override

6/14/13.. 6/14/13... 1s External Initiated ** System **

review
6/14/13.. 6/14/13... 1s External Requested ** System ** Check

review requested
6/14/13.. 6/14/13... 1s External Assigned ATEAM/SUPERVISOR

review
6/14/13.. 6/14/13... 10s External Completed ATEAM/SUPERVISOR Overridden

review
Within the step history details of the execution of each step are shown:

Configuring Exchange Steps
Step Document Setup

Within System tailoring | Step level documents the outward XML message details are defined as an
output document. This holds the event fields and event level customised fields to be sent to the
external system to be returned populated or changed by the external system and returned in the
response message to populate the event.
Within step level documents the supporting event data is defined to be sent and returned.


If no document is set up for a step the following error is presented:
See the Workflow Tailoring User Guide – FusionBanking Trade Innovation for details on setting up
external system links and the gateway documents for exchange steps.
See the Systems Interfacing Guide – FusionBanking Trade Innovation for details on using the
deferred response mechanism.
Exchange Step Execution

The gateway message viewer includes previous messages for this event. Gateway creation and a
watch list check message in this case.
The user can optionally override the warning. Confirm will complete the step.
The gateway message is sent. The step status is set to Requested. The step is assigned to the
appropriate team/user using the round robin rules. Normally the step is completed automatically on
receipt of the response message. If the step requires user intervention it is already assigned to a team
and/or user.

The gateway response message used is dependent on the event.

All messages allow the enriching of collateral, margin deposits and FX contracts where applicable.
The message formats used are the same as those available when receiving a request from a
corporate front end.
The following messages are available for enriching import transaction create events:
Message Description
TFCOLNEW New Collection
TFCPHCRT New Cheque
TFCPSCRT New Standing Order
TFFINNEW New Finance Transaction
TFIGTAPP New Import Guarantee
TFILCAPP New Import LC
TFINVNEW New Invoice
TFISBAPP New Import Standby
TFSHGAPP New Shipping Guarantee
The following messages are available for enriching import transaction amend events:
Message Description
TFIGTAMN Import Guarantee Amendment
TFILCAMN Import LC amendment
TFINVAMN Invoice Amend
TFISBAMN Import Standby amendment
The following gateway messages are provided for enriching export create and amend events:
Message Description
TFEGTNEW New Export Guarantee
TFEGTAMD Export Guarantee Amendment
TFELCNEW New Export LC
TFELCAMD Export LC Amendment
TFESBNEW New Export Standby
TFESBAMD Export Standby Amendment
Payment events by virtue of being a payment request do not require the main details to be enriched
under exchange within that same event. What is required is the ability to attach documents via

exchange enrichment. For any event, documents and gateway actions can be received using the
generic TFRCVDOC response message.
This covers the following events:
• Documents presented events
• Outstanding presentation events
• Claim received events
• Outstanding claim events
Subsidiary financing transactions created from within payment events can receive TFRCVDOC
messages. The exchange step would be in the parent event orchestration but the response messages
are received against the subsidiary financing event product/event. All subsidiary event responses
should be returned before returning the response for the master event.
The following message is available for updates for payment events:
Message Description
TFRCVDOC Received Documents
Alternately for any event, documents and gateway actions can be received using the generic
response message TFRCVDOC.
When the response is received:
• If the criteria state has become true the step remains on the transaction step times list and is
executed.
• If the step is executed but there is no document defined for the step, an error is reported at
the step, it must be rejected to continue.
The XML message is returned within a deferred response message wrapper. The deferred response
can return errors and warnings to apply to the step.
Example Exchange Deferred Response Message

<?xml version="1.0" encoding="UTF-8"?>
<DeferredResponse xmlns="urn:control.services.tiplus2.misys.com"
xmlns:c="urn:common.service.ti.apps.tiplus2.misys.com"
xmlns:m="urn:messages.service.ti.apps.tiplus2.misys.com"
xmlns:n="urn:custom.service.ti.apps.tiplus2.misys.com"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<DeferredHeader>
<Service>TI</Service>
<Operation>TFILCAPP</Operation>
<Credentials>
<Name>Name</Name>
<Password>Password</Password>
<Certificate>Certificate</Certificate>
<Digest>Digest</Digest>
</Credentials>

<ReplyFormat>FULL</ReplyFormat>
<ReplyTarget/>
<Status>SUCCEEDED</Status>
<Details>
<Warning>Documents required to be re-confirmed</Warning>
<Warning>Check collateral</Warning>
<Info>Supporting information text</Info>
</Details>
<TargetSystem>ZONE1</TargetSystem>
<CorrelationId>74241</CorrelationId>
<TransactionControl>NONE</TransactionControl>
</DeferredHeader>
<m:TFILCAPP>
<m:Context>
<c:Branch>KBSL</c:Branch>
<c:Customer>WIC TOR</c:Customer>
<c:Product>ILC</c:Product>
<c:Event>ISI</c:Event>
<c:OurReference>ILC00001209BWW</c:OurReference>
<c:Team>Local</c:Team>
<c:BehalfOfBranch>KBSL</c:BehalfOfBranch>
<c:EventReference>ISS001</c:EventReference>
<c:Step>Exchange</c:Step>
</m:Context>
<m:EventNotificationss>
<m:EventNotifications>
<m:MessageData>Margin</m:MessageData>
<m:MessageDescription>Exchange: Margin verified</m:MessageDescription>
<m:MessageInfo>Manual</m:MessageInfo>
<m:MessageNumber>02</m:MessageNumber>
<m:Actioned>N</m:Actioned>
</m:EventNotifications>
<m:EventNotifications>
<m:MessageData>Instructions</m:MessageData>
<m:MessageDescription>Exchange: Instructions verified</m:MessageDescription>
<m:MessageInfo>Manual</m:MessageInfo>
<m:MessageNumber>03</m:MessageNumber>
<m:Actioned>N</m:Actioned>

</m:EventNotifications>
</m:EventNotificationss>
<m:Beneficiary>
<c:Customer>DEIRA</c:Customer>
</m:Beneficiary>
<m:ExpiryDate>2014-12-31</m:ExpiryDate>
<m:ExpiryPlace>USA valid</m:ExpiryPlace>
<m:Documents>Test DCS1 1
Test DCS2 2
Test DCS4 4
Test DCS3 3</m:Documents>
<m:AdditionalConditions>further conditions</m:AdditionalConditions>
<m:InstructionsToAdvisingBank>Further ins to advising bank</m:InstructionsToAdvisingBank>
<m:InstructionsToPayingBank>Further ins to paying bank</m:InstructionsToPayingBank>
</m:TFILCAPP>
</DeferredResponse>
Error and Warning Responses

• An error returned cannot be overridden in the system, the step must be rejected.
• A warning returned can be overridden in the system as any system generated validation
warning.
See the SDK Systems Interfacing Guide – FusionBanking Trade Innovation for configuring request
and response messaging.
After a response is received (with a fail condition) the following is displayed:

Warnings can be overridden and the step can be confirmed.

If an error is returned the step must be rejected.
For exchange steps, under Reject there is a Repair function. The user can use the Repair function to
open the step in Input mode to correct details and revalidate.

Within the step history details of the execution of each step are shown. For exchange steps the step
status history shows both the system generated check request and either the completion by reply
message or manual completion by a user. The User action selected is included in the status history in
the Step action column.
Check followed by User Confirm or Repair

6/14/13.. 6/14/13... 1s Exchange Initiated ** System **
6/14/13.. 6/14/13... 1s Exchange Requested ** System ** Request sent
6/14/13.. 6/14/13... 1s Exchange Assigned ATEAM/SUPERVISOR
6/14/13.. 6/14/13... 10s Exchange Completed ATEAM/SUPERVISOR Overridden

The step history View function can show exchange step response details at any time.
If checks are repeated after a rejection then the repeat sequences of step responses are separately.

Available Balance Checking

Available balance checking is an integral part of input and review activities. Therefore the checks are
not provided as a separate step type but are available in all mapped input and review steps. The
available balance check is repeated in the release step.
Step Handling under Reject and Abort Actions

Where an event has more than one active step if a step is rejected back, that step is displayed as
Rejected. If another parallel step must be re-run as a consequence of the rejection, that step is also
rejected. Where an event is aborted, all running steps are flagged as aborted.
Updating In-use Orchestrations where Events are in Progress

When an event is created it uses the applicable in-use orchestration. When that orchestration is
replaced by another (by pressing the Confirm in use? function for the not in-use copy), from then on
new events use the new in-use details. To answer the question; what happens to previous incomplete
events which started under the previous version? The answer is the events carry on to completion as
before using the orchestration that they started with. The previous version is not deleted but is made
obsolete to new events.
Removing Obsolete Orchestrations

Obsolete orchestration definitions remain in the system until no more events are using them. Once all
linked events are completed, obsolete orchestrations which have no links to work in progress
transactions are dropped from the zone under the End of Day housekeeping cycle under the action
‘Delete obsolete event orchestrations’.

Using Workflow in Conjunction with Provisional Events

Provisional event functionality is fully available in conjunction with standard and advanced workflow.
Where an event is defined as provisional, it will proceed through the steps as orchestrated under the
applicable orchestration parameter set details. Where the event repeats until completion of a final
event, each event iteration follows the same orchestration step sequence and conditions. Within user
roles however, for all steps the provisional instance can be selected and mapped separately. The
provisional event step sequence could be managed under one team and the final by another.
Using Workflow in Conjunction with Subsidiary Events

Subsidiary event functionality is fully available in conjunction with standard and advanced workflow.
Normally when creating events the orchestration in the parameter set effective for the banking entity
is used. For example an export credit agency facility drawdown/revolve event will follow the
orchestration defined. However some events are created as a by-product of another. In this case the
subsidiary event must follow the status of the creating event step by step. For example a financing
transaction’s create event can generate an export credit agency facility drawdown/revolve event. All
subsidiary events follow the orchestrations of the event creating them.
Input, Review & Final Review Steps User Control

The system includes additional security validation to ensure the same user does not undertake two
maker or checker type steps within one transaction.
• The maker step is the last data capture step before the verification phase. This can be an
input or exchange type step. Note that the same user could undertake successive log, input
or exchange steps but the user for the last of these steps cannot undertake a subsequent
review step (after the final limit check in the verification phase).
• Checker steps are any review and final review type steps in or transitioning into the
verification phase. The same user cannot undertake two reviews, even if another user has
reviewed an intervening step.
• External check type steps such as watch list check, limit check and external review steps are
not included in these checks. The Post release phase is not included in these checks.

The following example orchestration outlines these constraints under parallel processing:
• The ‘Review initial input’ step user is compared to previous data capture step - Input 1
• The other review step users compare to their previous data capture step - Input 2.
• Note that for a verification phase review step the user must be different to that from prior
review steps in all parallel lines leading into it.
This constraint exists by default for live operations.
This constraint can be removed for test systems by implementing the following zone general option:
• UserCapture Review - Value = ‘Yes’.

The same user can then complete all steps to which role and team authorisation has been given.

Monitoring Workflow Events

This chapter explains how the Dashboard, Master Browser and Master Summary represent workloads
within the context of steps, step phases and step types. Monitoring step history, step status history
and SLA step times are also included.
Overview
The system provides various means for banks to monitor and manage their workload for both
standard and advanced workflow:
• The Dashboard – provides monitoring of workloads by step, step phase and step type. This is
the main focus for the majority of users.
• External Dashboard – if implemented under advanced workflow, allows step status
information to be sent via XML messages to an external dashboard.
• The Master Browser – allows filtering transactions by orchestrated step or step type.
• Step history includes service request details, responses and team / user assignments.
• SLA event step times maintains a ‘Total remaining processing time’ for the critical path
through parallel step dependencies and a ‘Total remaining processing step activity’ for all
remaining steps to complete.
• SLA step time history shows running comparisons between step average times and actual
times taken (including time reprocessing steps after a reject action).
The Dashboard
The incoming messages section includes a link to any step level response External review or
Exchange messages which require repair. This passes the user to the Message Manager | External
review/Exchange step message manager.
The Overall totals - all transactions input status chart is presented by step phase to allow a
meaningful presentation of data where different steps are used in different parts of the business, both
within a zone and cross zone. Under parallelism an event could have a step configured to run in either
the data capture or verification phases, in this case the transaction is categorised under data capture.
Users must be given the security capability to view these charts.
All transaction steps – Input status:

The Team and user totals can be selected by step or by step phase:
Transaction steps by Phase:
- Or Transaction steps by individual step:
Where by individual step, this includes all active steps, which may be in progress for one event.
ETC times in hours are taken from the ‘Total remaining processing time’. Under parallelism this is the
remaining time through the critical path through to the release and print steps.
The Dashboard filters include the filter ‘Watch List check – user action’ to supplement filtering.
The Dashboard allows transaction event selection by:
Event step type (e.g. Log, Input, Review, Post release)
Any event step defined in the zone:

Where an event has more than one active step, multiple entries are displayed. Select the entry for the
required active step in the results list.
Step status monitoring on the Dashboard

For the following step types gateway messages are sent to external systems and the step will await
the response:
• Exchange
• External review
• Watch list check
For these steps the status is presented as Requested. If a response is received and the step requires
user intervention to complete, the following status is presented to inform the user to take action.
Received - attn reqd (attention required). Pended events include the same information.
Populating an External Dashboard

If implemented, the system provides a publishing service to subscribers to provide updated event step
status details of event step transitions available to be monitored in an external dashboard. The same
general information as available in the system s work in progress columns can be provided to an
external system via XML messages. Items which hold a long and short name are provided in both
forms, for example the Step ID and Step description.
See the SDK Systems Interfacing Guide – FusionBanking Trade Innovation for instructions on how to
configure the publishing and subscription parameters.
The Master Browser

The Master Browser provides combinations of selection criteria which depending on granularity allow
the following levels of information to be returned:
• Master level details
• Event details
• Active event step details

The filters available within the Master Browser are grouped into three sections. Master, event and
step level filters.
Monitoring Master Details on the Master Browser

Selecting filters from the top section return Master level column status information:
Monitoring Event Details on the Master Browser

Selecting filters within the section highlighted in orange return Event level column status information.
The filter ‘Event status’ allows events which are ‘In progress’, ‘Completed’ or ‘Aborted’ to be listed.

Step status monitoring on the Master Browser

Selecting filters in the section highlighted in red return Active step level column status information:
the response:
• Exchange
• External review
• Watch list check
For these steps the status is initially presented as Requested.
When a response is received and the step requires user intervention to complete, the following status
is presented to inform the user to take action - Received.

The Master Summary

The Master summary presents the following under workflow orchestration:
Work in progress list – a tree view list is provided, initially collapsed per event, expandable to show all
active steps under the event. Individual steps can be continued, viewed or edited. Refresh, Abort and
Step history are available for the event.
Step Status Monitoring on the Master Summary

the response. The extra information is presented as follows while awaiting:
• Exchange steps – Request sent
• External review – Check underway
• Watch list check – Check underway
Presented as follows after the response has been received:

• Exchange steps – Response received
• External review – Response received
• Watch list check – Actual watch list response e.g. Funds blocked
Step History & Step Status History

The step history allows the user to drill-down individual steps or multiple steps to the step status
transition details using the [+] function:
Details of activity within a step can be viewed. Pressing [-] returns to the step history view.
Steps are not automatically assigned to the user who actions them. Steps and subsequent steps
remain assigned to the team where a step is not directly assigned to a user on a Pend action.

• The ‘Last action user’ indicates the last user undertaking the step.
• Step status actions undertaken by the system are flagged as ** System ** under the last
action user.
A View function is provided for all step types which undertake specific call outs for data on behalf of
the event.
See Watch List Checking, External Review Step and Exchange Step Step Execution sections in
Chapter 5 for examples.
Monitoring SLA Step Times
Transaction Times
To cater for parallel processing, the SLA details held for the event maintain two transaction times:
• ‘Total remaining processing step activity’ contains the total time of all the remaining steps
which are Always or Criteria which are currently met. This figure is net of time already taken
under the active steps.
• ‘Total remaining processing time’ contains the total time of the critical path of all the remaining
steps which are Always or Criteria which are currently met. This figure is net of time already
taken under the active steps.

Note that both remaining times re-set where a reject step branch is used, as in this case a separate
path of steps are introduced to release the event.
Step Times
Standard and advanced workflow allows the progress of the event at the step level to be monitored by
comparing the time spent in each step against average expected times. Details are accessed in each
event from the left menu bar item Other|Service level details.
The average step times are used as the basis for comparison against the actual times spent per step
in the transaction. A running comparison is made against the estimated ‘average’ time. The time
remaining or time overdue is shown alongside the step.
If during review the transaction is rejected, the repeat time spent repeating previous steps is included
in the average time comparison. See in the above example.
The SLA step times table shows all executed and future steps in a list. Parallel sequences are
presented by listing each parallel section in series, one after the other.
The following example includes rejection in the main line and then down the reject line:

Gateway Step Response Messages Repair

The Message Manager application groups internal transaction messaging in a separate section to
customer incoming and outgoing messages.
Internal transaction messaging | External review/Exchange step messages allows unmatched

messages to be repaired and re-processed. For Exchange and External review steps these match
against the event step, this will fail if the event is locked at the time of receipt. The step should be
pended to release the lock; then the message can be re-processed from the message manager
maintenance. Minimal correction to the messages itself is permitted as the messages structure should
be dependably set in the external system.
External review/Exchange step messages requiring attention are also highlighted and accessible for
repair from the Dashboard in the Incoming messages pane at the top of the Dashboard.
Two general failure cases are anticipated:
• ‘Step is not the current step for the event’. The step has been manually completed by
overriding the warning ‘No response has been received for the current step’. The step has
been completed. The message in the message manager should be deleted. If the step is
repeated a new request is made with a different correlation ID requiring a new response to
that ID.
• ‘Step is currently in use’. If the step is locked by a user at the time the message is received.
The user should exit the step. The message can be reprocessed by pressing Edit and OK. No
data is required to be changed.
If a message failed to be matched due to the message being badly formatted, or the step identifier is
not present in the transaction orchestration then this should not be resolved by repairing the
message. Exchange and external review communications should be undertaken where the basic
identifiers and fields are reliably correct.

Errors and Warnings Presented Across Parallel Steps

Errors and warning messages are associated with the step which created them. Messages are
presented according to the following principles:
• Errors only appear in the step to which they relate.
• Warnings generated in a step only appear in other steps after the step they relate to is
completed.
• Overridden warnings persist after rejecting back to prior steps.
• Within data capture Input and exchange steps, where data changes, previous overridden
warnings are hidden if the conditions that created them are no longer present.
• Where a step is repeated after a rejection, Overridden previous warnings are present.
Previous step details can be browsed historically using the View function in the step history.
This presents the actual warning override applicable to that individual step execution. The
View function is available to the following step types:
• Exchange steps
• External review steps
• Watch list check steps
User-defined Warnings optionally re-issued under review

verification
Where orchestration templates include multiple Input or Exchange type steps such that data is added
progressively; once a warning is overridden in one step, the same warning is not repeated in the next.
The user should not have to repeatedly override the same warning in successive steps. The warning
override from the previous step is treated as already addressed in the next. This behaviour also
applies to user defined warnings.
This non-repetition is not carried over into review steps as these may run in parallel requiring each
warning to link to an individual step. User defined warnings may include API calls to check external
statuses. Where these are connected with review steps each warning can check repeatedly for status
changes.
Where user defined warnings are not required to repeat into the verification phase, the bank must
ensure the warning is additionally conditioned on the data capture phase. See following example:

Note: Where banks are defining user defined warnings specifically for use within review steps (for
external system checks under the verification phase), the above phase condition is not required.
Event Field Requirements under Parallel Step Model
Event Fields Deprecated Under Parallel Processing

Some fields have been deprecated for use in the system at release 2.5. Event fields with the suffix ‘-
sequential orchestration’ are available under 2.5 but are for use solely for transactions using a linear
template (where no parallel links are defined). See the 2.5 release notes for details.
New event fields are provided for event and step related information for use within parallel and linear
orchestrations.
Customised Warnings Used Within Verification Phase

Because of the validation required in the system release step, banks which have user defined
warnings checking during review/authorisation steps will need to include an additional clause to stop
them also being generated on release. For example:

The following event fields are available to condition against for the release phase of an event:
REL – Event release – is Y (true) if the last verification step is completed through to completion of the
event.
RELD – Event release – is Y (true) if the release step itself is completed through to the completion of
the event (this would include print and post release steps).
RELG – Event releasing – is Y (true) if the last verification step is completed up to completing the
release step (this includes Rate fixing, Rate fix authorisation, Release pending and Release steps).

Appendix A Example Workflow for a Hub and Spoke Operation
Appendix A Example Workflow for a Hub and Spoke

Operation
This appendix is intended to provide an illustrative example of how to set up teams and users to take
advantage of the capabilities of standard workflow and advanced workflow.
Teams can be set up according to the customer service requirements. Services can be split into a
spoke and central hub:
• Spoke – a local walk in branch that would provide a logging and printing function. This is
typically the branch that will actually maintain or have responsibility for the client accounts and
/ or will maintain the ‘client relationship’.
• Central /Hub – Typically will undertake the actual processing of ‘standard or business as
usual’ transactions on behalf of the spokes; the port of call for any follow-on enquiries or
payments. May however also be a ‘specialist’ centre focusing on a particular business stream
such as oil credits.
Alternately there can be three tiers, spoke, regional and central:
• Regional – Typically the ‘controlling’ branch for the spokes. This branch will usually make the
decisions around pricing structures, facilities and limits and service levels. May also provide
specialist / dedicated services for premium clients, or handle ‘high value’ transactions.
The example given follows the two tier described in the Global Processing Implementation Guide –
FusionBanking Trade Innovation.
Setting up Routing to Teams and Users

Work can be routed to teams at the appropriate time in the workflow based on either initial
assignment, Event/Team mappings or according to ‘Round robin’ rules.

Initial Routing to Teams or Team/Users on Event Creation

The system provides a way of routing transactions to the teams and users who will initially work on
them. This is achieved as follows:
All transactions are associated with a branch and team at the creation of the event.
• When a user creates a new event from the dashboard or master browser, they must specify
the team and behalf of branch for which the transaction is being created.
• When an event is created from SWIFT, the behalf of branch is determined from the receiver
BIC in the SWIFT header. This branch is then used to determine the work allocation. Where
there are no event team mappings or suitable team found, the system will assign the
transaction to the default team defined on the branch product options. If a team cannot be
determined, the transaction will be assigned to the SWIFT repair team. From here it can be
manually re-assigned to the correct team.
• A team can be specified on an incoming Gateway message. Where there are no event team
mappings or suitable team found, the system will assign the transaction to the default team
defined on the branch product options. If a team cannot be determined, the transaction will be
assigned to the Gateway repair team.
The system assigns this team/user as the responsible team/user for the master. These values are
held against the master record to provide a point of contact for information regarding the transaction.
Routing to Teams or Team/Users on Change of Step

After the team has initially been determined for the first step, as the transaction moves to the next
step, the system automatically assigns it to a team or team/user that can perform the next step using
the following order of lookup:
• Team or Team/User based of the event team map; this allows rules to be set up to route work
to specialist teams.
• The current team if the team has the role to be able to complete the step.
• The next available team on a round robin basis (in alphabetical order). The system will
attempt to assign the transaction to teams flagged as suitable for auto-allocation of work first.
If no auto-allocate teams are found then the standard teams are used.
• If there are no teams available, then the system will assign the transaction to the default team
for the product. This assignment is controlled by parameter sets so different branches can
have different team defaults.
For information on setting up Event/Team mappings see the System Tailoring User Guide –
FusionBanking Trade Innovation.
The following example concerns a single event. For setting up Event Groups for grouping multiple
events see the Global Processing Implementation Guide Appendix C – FusionBanking Trade
Innovation.
Setting up Teams with User Roles

For a two tier Spoke and Hub environment for example, to process an Import Letter of Credit issue
event, three teams could cover the following areas:
• Branch team for initial logging and final print (Local-Log)
• Hub team for input and review (LCHub-InpRev)
• Branch management team for post-release checking (Local-MgmtRev)

This setup ensures no overlap between logging staff and post release management review staff. This
example involves teams containing a number of roles. The roles are assigned to users according to
authority. Roles are required to assign groups of steps to teams and team users.
In this example there is a single event group containing the ILC issue event. For information on
setting up Event Groupings see the Plus Global Processing Implementation Guide – FusionBanking
Trade Innovation.
Identifying the User Roles

An example orchestration is as follows. The required hub and spoke requirements are shown:
Step Description Step Type Spoke Hub Team
Log Log Local-Log
Limit check Limit check Local-Log
Input Input LCHub-InpRev
External review External review LCHub-InpRev
Watch list check Watch list check LCHub-InpRev
Limit check 2 Limit check LCHub-InpRev
Exchange Exchange LCHub-InpRev
Final limit check Final limit check LCHub-InpRev
Review 1 Review LCHub-InpRev
Review 2 Review LCHub-InpRev
Authorise Review - final LCHub-InpRev
Final print Print Local-Log
Post release 1 Post release Local-MgmtRev
Post release 2 Post release Local-MgmtRev

Assigning Steps to User Roles

The following roles allow teams to be assigned the steps of each phase required. This example also
allows the external checks to be assigned to a separate team for approval:
Role ID Role Description Event Group
ILC-Log ILC Log ILC-Issue
ILC-LogApp ILC Log Approval ILC-Issue
ILC-Input ILC Input ILC-Issue
ILC-InputApp ILC Input Approval ILC-Issue
ILC-Review ILC Review ILC-Issue
ILC-FinalReview ILC Final Review ILC-Issue
ILC-FinalPrint ILC Final Print ILC-Issue
ILC-PostRelease ILC Post Release ILC-Issue
Individual steps are then assigned to roles.
Note that on selecting a step, assigned or unassigned, the Where used... function tells the user which
in which templates, orchestrations and parameter sets the step is currently defined in. This ensures
correct selection of the required steps for the business context.

Note. The relevant system steps are also required to be mapped. For example without authority to the
create step, the user cannot initiate the event.
The following steps are mapped to the roles:
Role ID Role Description Event Group Assigned Step Description
ILC-Log ILC Log ILC-Issue Create

Abort
Log
ILC-LogApp ILC Log Approval ILC-Issue Abort – Abort

Limit check
ILC-Input ILC Input ILC-Issue Abort – Abort

Input
Exchange
ILC-InputApp ILC Input Approval ILC-Issue Abort – Abort

Limit check 2
Final limit check
Watch list check
ILC-Review ILC Review ILC-Issue Abort – Abort

Review 1
Review 2
ILC-FinalReview ILC Final Review ILC-Issue Abort – Abort

Authorise
ILC-FinalPrint ILC Final Print ILC-Issue Final print
ILC-PostRelease ILC Post Release ILC-Issue Post release 1

Post release 2

This allows separation of the various spoke and hub roles by job function using the steps allowed.
Identifying Teams
Teams are required to operate within the hub and spoke operation. Teams are defined around
independent functions of the business. One team is required for users logging and final printing after
completion, a separate team for the hub input and verification tasks and a management user team for
post release oversight. This ensures that users only see transactions relevant to them on the
dashboard.
Example teams: Local-Log, LCHub-InputReview & Local-MgmtReview
Assigning Roles to Teams

Teams can be mapped to roles as follows:
Team ID Team Description Roles
Local-Log ILC Log & Print ILC-Log

ILC-LogApp
ILC-FinalPrint
LCHub-InpRev ILC Input & Review ILC-Input

ILC-InputApp
ILC-Review
ILC-FinalReview
Local-MgmtRev ILC Management Review ILC-PostRelease
Setting up Teams with User Roles
Assigning Users to Teams

Users are assigned to teams. Then only the roles appropriate to each user are assigned to each.

Setting up Users in Teams
Local Logging & Approval Users

User Team Assigned Roles
LOGUSER1 ILC-Log ILC-Log
LOGUSER2 ILC-Log ILC-Log
LGAPRVUSR1 ILC-Log ILC-LogApp
PRINTUSER1 ILC-Log ILC-FinalPrint
LOGSUPER1 ILC-Log ILC-Log, ILC-LogApp, ILC-FinalPrint
LC Issue Hub Input & Approval Users

INPUTUSER1 LCHub-InpRev ILC-Input
INPUTUSER2 LCHub-InpRev ILC-Input
INAPRVEUSR1 LCHub-InpRev ILC-InputApp
INPUTSUPER1 LCHub-InpRev ILC-Input, ILCInputApp
LC Issue Hub Review Users

REVUSER1 LCHub-InpRev ILC-Review
REVUSER2 LCHub-InpRev ILC-Review
LC Issue Hub Final Review Users

FINREVUSER1 LCHub-InpRev ILC-FinalReview
FINREVUSER2 LCHub-InpRev ILC-FinalReview
FINRVSUPER1 LCHub-InpRev ILC-Review, ILC-FinalReview

Local Management Review Users

MGRREVUSER1 Local-MgmtRev ILC-PostRelease

Appendix B SDK Components in Action
Appendix B SDK Components in Action

This appendix provides an example of how the various components of Advanced SDK can be
deployed to provide systems integration solutions.
The diagram shows some of the types of systems integration that may occur in banks:
This involves the customer, spoke and hub teams within the application, a document management
system (DMS) and a number of additional bank systems (external systems).
Each box represents a process with decision points at various stages that would be set as criteria on
the step set up within the system.
Each component that is involved in the integration is shown with a key as follows to illustrate which
SDK components may be required:
• Key
• WO – Workflow Orchestration
• EPI – External Process Integration
• EX – Exchange Step
• RV – External Review Step
• ADE – Application Data Extension
Process 5a is an optional parallel workflow to refer a high value transaction to a relationship manager
(RM). External to the system the bank could refer on to other departments such as to consider the
transaction for syndication. Once all the other bank processes are complete a single response to
process 5a is provided back to the system.
Process 9 in red is an exception rejection workflow.

Appendix C Associated Documentation
Appendix C Associated Documentation

Full details relating to the installation of this release and details on configuring the system are covered
in the accompanying documents:
• Global Processing Implementation Guide – FusionBanking Trade Innovation
• Workflow Implementation Guide – FusionBanking Trade Innovation
• Workflow Tailoring Guide – FusionBanking Trade Innovation
• System Tailoring Guide – FusionBanking Trade Innovation
• Static Data Guide – FusionBanking Trade Innovation
• Configuration Management Tool Guide – FusionBanking Trade Innovation
• SDK – Common Facilities Guide – FusionBanking Trade Innovation
• SDK – Systems Interfacing Guide – FusionBanking Trade Innovation
• SDK – Systems Integration Guide – FusionBanking Trade Innovation
• SDK - Application Extension Guide – FusionBanking Trade Innovation
• SDK – Screen Tailoring Guide – FusionBanking Trade Innovation
• SDK – Data Management Guide – FusionBanking Trade Innovation

Glossary of Terms
Glossary of Terms
The following table provides a list of special terms used in this Guide and explains what each means:
Advanced workflow Event orchestrations can be configured for business entities using
parameter sets, new step IDs can be created and assembled into template
sequences for use in orchestrations mapped in business entities
throughout the zone.
Parallel workflow A workflow using a template with at least one parallel section, where
multiple steps can be scheduled simultaneously.
Data capture steps These are the log and input step types. All log steps must precede all input
steps in a template.
Verification phase The phase in workflow where data is being checked for authorisation.
Review steps and final review steps are undertaken exclusively in the
verification phase. No data entry is possible in steps in this phase.
Verification steps These are the review steps (including the final review step and the watch
list check steps). These can be mapped in both the data capture and the
verification phase.
Release phase An internal phase generated by the system to handle the release of the
event. This may include a release pending step if the end of day is running
with extended hours input.
Post release phase The phase in workflow where the event outputs have already been
released. The print step is exclusively available to this phase, allowing
printing documents in the originating branch. The post release step is
exclusively available to this phase allowing managers to view event details.
Post release steps These are the print step and post release management review steps
available only within this phase.
Steps Users can create step definitions for sequencing within template
definitions. A sequence of steps available to be incorporated into a
workflow orchestration.
System steps Steps which are never orchestrated by the user. These steps are managed
automatically by the system. For example Create, Abort, Release &
Complete.
Exchange step A template step which allows event data to be populated from an external
system. This data must be reviewed within the system before completing
the step.
External review step Queries can be made and their responses received and stored against the
step. Depending on the auto-complete flag, the step can auto complete or
require user action to continue.
Synchronisation step An internal step available to build complex dependency relationships -

many to many links.
Spoke The spoke operations comprise the local branches acting a service centre
where customers can make initial applications. In such a setup a bank can
offer local customer facing services, for example receiving and scanning
documents received from a customer, negotiating FX contracts and
checking limits and printing out documents for the customer.

Glossary of Terms
Hub The hub operations comprise a centralised centre of excellence for further
data entry and for checking the workability of the customers’ requests. The
hub would typically complete the data entry and any additional checks such
as for watch list compliance. The transaction would then proceed through
one or more review steps before items such as SWIFT messages and
accounting entries are released.
Templates A sequence or linked set of sequences of steps available to be

incorporated into a workflow orchestration.
Workflow orchestration Includes the conditions and run attributes applying to the steps defined in
the associated template. An orchestration definition is required for each
event.
Final limit check This is a system step triggered as the event crosses the end of the data
capture phase if the limit reservation has not been made already under an
orchestrated limit check action.
In-use An orchestration for an event in a parameter set, which is ‘live’. This

parameter set is controlling the steps used in events created within behalf
of branches under the banking entities mapped to the Orchestrations
parameter set.
Not in-use An orchestration definition which is available for editing prior to being
utilised. It has no effect on transactions until being made in-use.
Obsoleted orchestrations When a new orchestration definition is made in-use, the previous version is
no longer available to users, but remains in the system until all transactions
using it have completed and are booked off. The end of day housekeeping
phase deletes obsolete orchestrations which are no longer controlling
transactions.
External API callout The standard event status details presented on the Dashboard and Master
Browser are also available to publish to external subscribing systems via
API XML messages, using topics or queues. See the SDK – System
Interfacing Guide – FusionBanking Trade Innovation for details.
UI User Interface – Used in the context of being able to change the default
behaviour of the log and input screens.

SDK - Workflow Implementation Guide - FusionBanking Trade Innovation 27

Uploaded by

Copyright:

Available Formats

You might also like

SDK - Workflow Implementation Guide - FusionBanking Trade Innovation 27

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

SDK - Workflow Implementation Guide - FusionBanking Trade Innovation 27

Uploaded by

Copyright:

Available Formats

Misys FusionBanking Trade Innovation 2.

Release month and year: October 2015

The Default Workflow Orchestrations ................................................................................................... 23

© Misys | SDK - Workflow Implementation Guide - FusionBanking Trade Innovation 2.7 iv

Removing Obsolete Orchestrations ...................................................................................................... 64

© Misys | SDK - Workflow Implementation Guide - FusionBanking Trade Innovation 2.7 v

Chapter 1 Provides an introduction to the principles of advanced workflow.

Chapter 2 Provides an overview of advanced workflow.

Chapter 3 Discusses how a bank should go about implementing advanced workflow.

Appendix C Provides a list of associated documentation.

© Misys | SDK - Workflow Implementation Guide - FusionBanking Trade Innovation 2.7 vi

FusionBanking Trade Innovation and Workflow

What is Advanced Workflow?

© Misys | SDK - Workflow Implementation Guide - FusionBanking Trade Innovation 2.7 1

Varying the Data in Each Step

The Use of Other SDK Components in Workflow

© Misys | SDK - Workflow Implementation Guide - FusionBanking Trade Innovation 2.7 2

Integration between Workflows and Other Systems

Integration between FusionBanking Trade Innovation and Other

Licensing Levels of Workflow – ‘Standard’ and ‘Advanced’

© Misys | SDK - Workflow Implementation Guide - FusionBanking Trade Innovation 2.7 3

The Basic Components of Workflow

© Misys | SDK - Workflow Implementation Guide - FusionBanking Trade Innovation 2.7 4

The Event Phases within Workflow

© Misys | SDK - Workflow Implementation Guide - FusionBanking Trade Innovation 2.7 5

The Standard (Default) Workflow Orchestration

© Misys | SDK - Workflow Implementation Guide - FusionBanking Trade Innovation 2.7 6

• Print step (for final print)

Creating Steps for Bank Defined (Advanced) Workflows

Each step created of each type incorporates the following:

© Misys | SDK - Workflow Implementation Guide - FusionBanking Trade Innovation 2.7 7

Sequencing Steps into Templates

Data Capture Phase

© Misys | SDK - Workflow Implementation Guide - FusionBanking Trade Innovation 2.7 8

Post Release Phase

Example Parallel Workflow

© Misys | SDK - Workflow Implementation Guide - FusionBanking Trade Innovation 2.7 9

Example Parallel Workflow Utilising Reject Step Branch

© Misys | SDK - Workflow Implementation Guide - FusionBanking Trade Innovation 2.7 10

Steps can be added in from the available steps list.

© Misys | SDK - Workflow Implementation Guide - FusionBanking Trade Innovation 2.7 11

Minor Process To cover events requiring minimal Input, Authorise

System Managed Steps

© Misys | SDK - Workflow Implementation Guide - FusionBanking Trade Innovation 2.7 12

Limit Checking Automation

© Misys | SDK - Workflow Implementation Guide - FusionBanking Trade Innovation 2.7 13

Orchestrations under Advanced Workflow

Overall Orchestration Parameters

© Misys | SDK - Workflow Implementation Guide - FusionBanking Trade Innovation 2.7 14

Attributes can be set for the step configured in the template.

© Misys | SDK - Workflow Implementation Guide - FusionBanking Trade Innovation 2.7 15

External Review Steps

Configuring Fields Available in Log or Input Steps

© Misys | SDK - Workflow Implementation Guide - FusionBanking Trade Innovation 2.7 16

The Dashboard and Master Browser

© Misys | SDK - Workflow Implementation Guide - FusionBanking Trade Innovation 2.7 17

Watch List Checking

Populating an External Dashboard

The following details are provided: