Service Requirement
Doc Name
Doc Title
1
Service Requirements
2
Another Line
3
Status: Final
4
Version 1.03
5
April 4th 2012
6
Page 1 of 18
Service Requirement
7
TABLE OF CONTENTS
8
TABLE OF CONTENTS.............................................................................................................................................. 2
9
1.
10
11
12
13
14
15
16
17
INTRODUCTION............................................................................................................................................... 3
1.1
1.2
1.3
1.4
1.5
1.6
1.7
2.
18
19
20
21
DOCUMENT CHANGE CONTROL .............................................................................................................................3
DOCUMENT APPROVERS.......................................................................................................................................3
ABBREVIATIONS /ACRONYMS................................................................................................................................4
REFERENCES ......................................................................................................................................................4
LOCATION IN SERVICE CATALOGUE..........................................................................................................................4
PURPOSE ..........................................................................................................................................................4
INTENDED AUDIENCE...........................................................................................................................................5
SCOPE AND WORKING ASSUMPTIONS ............................................................................................................ 5
2.1 SCOPE ..............................................................................................................................................................5
2.1.1 In Scope .............................................................................................................................................5
2.1.2 Out of Scope......................................................................................................................................6
2.2 WORKING ASSUMPTIONS .....................................................................................................................................6
22
3.
FULL LIST OF HIGH-LEVEL REQUIREMENTS IN THIS SERVICE ............................................................................ 6
23
4.
DETAIL REQUIREMENTS .................................................................................................................................. 6
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
4.1 TRIGGER AAA PROCESSING ..................................................................................................................................7
4.1.1 Vanilla Flow: Use of Business Rules ..................................................................................................7
4.1.2 Suppress AAA ....................................................................................................................................7
4.1.3 Postpone AAA for a AAAA in Normal Flow........................................................................................7
4.1.4 File Handling......................................................................................................................................8
4.1.5 Specification: To XYZ .........................................................................................................................8
4.2 HANDLE AAA RESULTS ........................................................................................................................................9
4.2.1 AAAA R Handling .............................................................................................................................10
4.2.2 AAAA format of R from XYZ ............................................................................................................11
4.3 HANDLE AAA EXCEPTIONS .................................................................................................................................11
4.3.1 Re-AAA (Replacateing to XYZ) .........................................................................................................11
4.3.2 Manual Release of AAAAs in ‘Postpone AAA Mode’ .......................................................................11
4.3.3 BOLD History during ‘AAA Mode’....................................................................................................12
4.3.4 BOLD Enquiry during ‘Postpone AAA Mode’ ...................................................................................12
4.4 MANAGE AAA POSTPONE MODE........................................................................................................................12
4.4.1 AAA in Business Contingency ..........................................................................................................12
4.4.2 Mockups ..........................................................................................................................................13
4.4.3 Risk Assessment ..............................................................................................................................14
42
5.
SPECIFIC NON-FUNCTIONAL REQUIREMENTS ................................................................................................ 14
43
6.
IMPACT ON OTHER SERVICES ........................................................................................................................ 14
44
7.
RISK ASSESSMENT ......................................................................................................................................... 15
Page 2 of 18
Service Requirement
45
8.
46
47
48
49
50
51
52
53
54
55
APPENDIX ..................................................................................................................................................... 15
8.1 FILE ATTACHMENTS ..........................................................................................................................................15
8.1.1 List of BOLDs with AAA Requirement..............................................................................................15
8.1.2 XYZ AA Interface Document ............................................................................................................15
8.2 OTHER ...........................................................................................................................................................15
8.2.1 Technical details ..............................................................................................................................15
8.2.2 TTT DD workflow .............................................................................................................................15
8.2.3 TTT SS Workflow .............................................................................................................................15
8.2.4 Current AAAA Flow between GGG and XYZ ....................................................................................16
8.2.5 Sample AAA Table ...........................................................................................................................17
8.2.6 Sample Set Criteria Table ................................................................................................................17
56
57
1.
58
1.1
INTRODUCTION
DOCUMENT CHANGE CONTROL
59
60
Version
0.1
0.2
Date
6th Mar 2012
9th Mar 2012
Author
XXX
XXX
0.3
12th Mar 2012
XXX
1.2
Change
Initial Document Creation
Updated document post comments from XXX and
walkthrough with SMEs.
Updated
DOCUMENT APPROVERS
61
Submission
Date
R Date
Signed-off/
Informed
04/04/2012
04/04/2012
04/04/2012
04/04/2012
Lead
Lead
04/04/2012
04/04/2012
Deploy/Roll-out
04/04/2012
04/04/2012
Lead
04/04/2012
05/04/2012
Lead
04/04/2012
04/04/2012
SME Team
62
63
Page 3 of 18
Role
Name
Service Requirement
64
1.3
ABBREVIATIONS /ACRONYMS
65
Abbreviation / Acronym
Abc
Description
abc
66
1.4
REFERENCES
67
68
Refer to Service Implementation Documents for each business flow for examples of how the functionality in this
service is used (e.g. Business Rules/Decision Tables etc.)
69
70
Refer to Workflows to see the complete picture of how this service is used in context of the overall Inbound and
Outbound flows.
Reference
1
71
1.5
Documents
abc
Issue Date
Author(s)
Location
link
LOCATION IN SERVICE CATALOGUE
72
73
Area
Functional
74
75
Level 1
Legal and
Compliance
76
77
Level 2
Regulatory
Filtering Support
78
79
1.6
80
The L1: regulatory requirements on:-
81
PURPOSE

82
83

84
85
86

Handover AAAAs to archival system (refer to Service Requirement Document for “Legal
Archiving”)
Handover audit trail and system logs to archival system (refer to Service Requirement
Document for “Legal Archiving”)
Integration of Regulatory AAA
The table below shows the high-level description of the Service:
Service
Description
Page 4 of 18
Service Requirement
L1 – Legal and
Compliance
Adhering to Legal and compliance requirements, archiving of AAAAs & other
information, maintaining audit trail and other AAA requirements.
L2 – Regulatory AAA
Support
1. Integration with regulatory AAA services for File or BOLD based AAAAs
2. Defines BOLD formats for integration with regulatory AAA services
application
3. Operational workflow for AAA processing
4. Handling the Rs
88
The main purpose of this service is to ensure that the AAAAs processed through the solution are
governed as per the xxx, xxx and xxx in place.
89
1.7
90
Selected vendor and following work streams counterparts
87
INTENDED AUDIENCE





91
92
93
94
95
IT build
Architecture and design
Requirements Analysis
Deploy/Rollout
Testing
96
SCOPE AND WORKING ASSUMPTIONS
97
2.
98
2.1
99
2.1.1 IN SCOPE
SCOPE
100
101
The scope of the document is limited to describe
102

103

104
105

106
The interaction between the ABC solution and XYZ
Business rules, which are used to select the required AAAAs for a AAA and also to assign criteria
sets and location ID
Postponed AAA mode for individual AAAAs as well as in case of a business contingency when
XYZ is not available
Next immediate steps a AAAA must follow on the basis of XYZ R.
107

108
All the requirements described in the document apply to TTT and SSS BOLDs.
Page 5 of 18
Service Requirement
109
2.1.2 OUT OF SCOPE

110
111

112
113
2.2
As all the AAAAs in a file will be de-bulked and then individual AAAAs will be sent for AAA, DDDD
(files) is out of scope.
The processing which takes place inside XYZ is also out of scope.
WORKING ASSUMPTIONS
114

115
116

117
118
The interaction, its formats and flow handling with XYZ (current version is 7.6) remain
unchanged
The selection of AAAAs and passing on relevant information (criteria set and location ID) to XYZ
remains with the ABC solution
119
120
3.
FULL LIST OF HIGH-LEVEL REQUIREMENTS IN THIS SERVICE
121
L2 (Service)
L3 (Service
Operation)
Requirement
ID
Requirement Detail
Applicable
for XXX*
Comments
Regulatory
Trigger
P52.001
The system must offer a
configurable exit point to
external AAA tool where org
can decide when to perform
check in the BOLD processing
flow
Y
Refer to
section 4.1
and 8.3.4
N
Y
122
123
*Y = Yes, N = No
124
4.
125
The “Regulatory AAA Support” service has four Level 3 service operations, namely:
126
127
Trigger AAA Processing – The implementation of business rules to determine if AAA is required, and whether or
not postponed AAA is needed.
128
Handle AAA Results – The process by which the ABC solution needs to process the R BOLDs received from XYZ.
129
130
Handle AAA Exceptions – The process whereby manual operator intervention is required in order to complete the
processing flow for 1 or more AAA related BOLDs.
DETAIL REQUIREMENTS
Page 6 of 18
Service Requirement
131
132
133
Manage AAA Postpone Mode – The process whereby operators can enable/disable global “postpone” switches,
which are then used in business rules to determine if AAA is postponed, meaning the BOLD continues in the
workflow towards it’s final destination, and a copy is sent to XYZ for later AAA.
134
135
Summary of requirements: org currently uses XYZ application to carry out the AAA against
regulator/compliance required listings.
136
4.1
137
4.1.1 VANILLA FLOW: USE OF BUSINESS RULES
138
139
140
141
142
143
144
145
146
TRIGGER AAA PROCESSING
These rules is:
o The decision on whether AAA is required (yes/no)
o Which instance of XYZ should be used for AAA
o The “criteria set” that XYZ should use to filter the AAAA against
o The “Location ID”
o All fields in the XYZ header to be filled properly
Please refer to section 8.2.5 for examples of business rules and filter criteria. (Refer to Service “Rule
Management” for detailed requirement on business rule configurations how to manage business
rules and requirements specific to the user exit code.)
147
148
149
150
151
152
153
154
4.1.2 SUPPRESS AAA
Similarly, for suppressed AAA, the ABC solution must check the value of the field “AAAResult” (refer
to Service Requirement Document for “Supplementary Data”) to identify whether the AAAA needs
to be suppressed for AAA or not.
 In case the field is non-empty, the AAAA must be suppressed for AAA
 In case the field is empty, the AAAA must follow the vanilla business rules (above) for a
decision on AAA
155
156
157
158
4.1.3 POSTPONE AAA FOR A AAAA IN NORMAL FLOW
to identify such AAAAs, these must use as inputs all fields of the Header and the fields, in addition to
custom user exits (refer to Service Requirement Document for “Rule Management”).
159
160
161
The ABC solution must then queue up a copy of AAAAs to XYZ whilst continuing on with the
processing of the AAAA.
162
Page 7 of 18
Service Requirement
163
164
Upon receiving the R for such AAAAs, the result must be updated in the field “AAAResult” (refer to
Service Requirement Document for “Supplementary Data”).
165
166
The BOLD history of such a AAAA must also be updated with the R from XYZ.
167
168
169
The R from XYZ for a postponed AAAA must not affect the processing steps of the AAAA, only to
update the BOLD history.
170
171
172
173
174
175
4.1.4 FILE HANDLING
The system should be possible to perform AAA for AAAAs bulked in files. This includes the activities
for abc AAAAs plus additional tasks like decompression and de-bulking of in individual AAAAs. Refer
to AAAA Transformation for further details on this.
4.1.5 SPECIFICATION: TO XYZ
1. The ABC solution must pass on a unique AAAA reference number to XYZ in order to match
the R from XYZ for the AAAA.
2. The ABC solution must handle multiple formats for placateing AAAAs for AAA.
 AAAAs must be sent to XYZ as line format (containing blocks 1 to 5) BOLD wrapped
in a XYZ header.
 The ABC solution must also support AAAAs in some format.
3. The ABC solution must be able to transform the AAAAs from the original format to a XYZ
format so that these AAAAs can be processed by XYZ.
4. The format in which the AAAAs are sent to XYZ must be configurable using business rules as
depending upon the AAAA, the XYZ instance to placate to will differ and in some cases be at
a different adapter version.
176
177
178
179
180
181
182
183
184
185
186
AAAA format of request to XYZ (TTT line BOLD):
Field No.
187
1
Field
Name
Mandatory
/Optional
Location
ID
M
Leng
th
Type
Content
Attributes
3
Alphanum
eric
Code separates traffic
into different streams
which can represent
locations/ depts/
branches which the user
can log into via the XYZ
Any 3 characters representing a
logical business. (e.g. AP2, U13)
Defined by business rules
Page 8 of 18
Service Requirement
user workstation
2
Request
Type
M
1
Character
Submit BOLD for AAA
Always submit
3
Trans
ref num
M
22
Alphanum
eric
Unique BOLD id for user
reference on the
messaging system
Unique related reference key
(RFK)
4
Format
Type
M
1
Character
BOLD Format
Always Freeform Unformatted:
‘U’
188
189
A sample BOLD displayed on the XYZ screen is attached for reference:
190
191
4.2
HANDLE AAA RESULTS
Page 9 of 18
‘S’
Service Requirement
192
193
194
195
4.2.1 AAAA R HANDLING
The unique AAAA reference that is passed on to XYZ along with the BOLD must be used to match
BOLDs with every relevant R from the XYZ application. The BOLD has to follow the next steps in
processing depending upon the R from XYZ as mentioned in the table below:
R Type
Process Type
Processing Steps
‘P’ (Passed)
‘M’ (Manual),
‘A’ (Automatic)
BOLD history updated with R type and BOLD to follow normal
steps in Processing flow
‘H’ (Hold)
‘M’ (Manual),
BOLD history updated with R type and BOLD must wait in the ABC
solution as it needs manual intervention by XYZ operator.
‘A’ (Automatic)
196
In case of a ”Failed” R from XYZ, the ABC solution must look up in the business rules to decide.
197
The ABC solution must support the use of the following information from the XYZ R in the
notification that must be sent using “AAAA Status Distribution” to placateer of the AAAA (refer to
Service Requirement Document for “AAAA Status Distribution”):
198
199
200
201


202
203
204

205
206
207
208
209

Reject Reason– SS Containing “FilterFail: “ (truncated according to length of field)
(Optional) Criteria Set –Header field to be defined in the Service “Supplementary Data”
(refer to Service Requirement Document for “Supplementary Data”) – to be taken from the
original BOLD to XYZ
(Optional) XYZ Operator ID –Header field to be defined (refer to Service Requirement
Document for “Supplementary Data”) “XYZOperatorID”. Contains the comma-separated
contents of “Opid1”, “Opid2”, and “Opid3” of the R when present and non-empty.
(Optional) Location ID –Header field to be defined in the Service “Supplementary Data”
(refer to Service Requirement Document for “Supplementary Data”). Contains contents of”
Location ID” from the original BOLD to XYZ.
210
This information must also be updated in the AAAA audit log.
211
The ABC solution must be able to handle multiple Rs from XYZ for a single AAAA. All the Rs received
must be updated in the AAAA history, but if the BOLD has already received a “Passed” or “Failed” R then
any subsequent Rs should not affect the flow of the BOLD.
212
213
Page 10 of 18
Service Requirement
4.2.2 AAAA FORMAT OF R FROM XYZ
Field No.
214
1
Length
Type
Content
Attributes
R Type
1
Character
XYZ’s R to the scanned BOLD
Pass
“P”
Fail
“F”
Hold
“H”
The fields: “Sdn_hit”, “Opid1”, “Opid2” and “Opid3“ will have information only if the AAAA was
manually reviewed in XYZ. In normal cases R structure will have blanks in all these fields.
215
216
217
Field
Name
All R fields must be available to be logged to the BOLD history log of the matched BOLD.
218
219
220
4.3
221
4.3.1 RE-AAA (REPLACATEING TO XYZ)
222
223
HANDLE AAA EXCEPTIONS
In the ABC solution, it must be possible to manually placate AAAAs to XYZ for AAA again in a single
or jazz mode
224
225
226
Additionally, when any changes are made to a AAAA that’s already filtered, it must be re-entered in
to the vanilla workflow to check again the AAA criteria and then resent to XYZ.
227
228
229
The process to replacate the AAAAs for AAA must be allowed to be repeated without any limitations
regardless of the R from XYZ. (refer to Service Requirement Document for ”Administration”)
230
231
232
The entitlement for the replacate option must be separate and must be assigned to a operations
user or an administrative user.
233
234
235
236
237
Every time a AAAA is sent for AAA, the audit log of the AAAA must be updated to log the following:
 Date & timestamp of the activity
 User ID of the ABC operator
 XYZ instance
238
239
4.3.2 MANUAL RELEASE OF AAAAS IN ‘POSTPONE AAA MODE’
Page 11 of 18
Service Requirement
The ABC solution must have a GUI function with defined entitlements which would allow an
operator to manually from XYZ to the normal flow. (refer to Service Requirement Document
for ”Administration”)
240
241
242
243
244
245
4.3.3 BOLD HISTORY DURING ‘AAA MODE’
This set of requirements describes the audit log maintenance and reporting requirements in case
AAAAs are processed in AAA Mode.
246
247
When the ‘AAA Mode’ is on, the audit trail for new AAAAs must be updated to indicate that the AAA
for all BOLDs that have been postponed i.e. the ABC solution must update the Header field “AAA”
with value “B” to indicate the postponed AAA. The AAA indicator is located in the Header in” (refer
to Service Requirement Document for “Supplementary Data”). When the Postpone AAA Mode is off,
refer to the Vanillia Flow.
248
249
250
251
252
253
4.3.4 BOLD ENQUIRY DURING ‘POSTPONE AAA MODE’
It must be possible to generate online enquiries in the ABC solution to reconcile the BOLDs
processed in AAA Mode and the corresponding XYZ Rs. The fields mentioned below must be used as
filter criteria to run the enquiry. The results must be viewable in the ABC solution directly by the
user running the enquiry. There must be a wildcard support for all filter criteria of reports. (Refer to
Service Requirement Document for “GUI & Usability”).
254
255
256
257
258



259
260
261
Postpone Filter Mode (Yes/No)
Placateer BIC
Receiver BIC
The output of the report must contain fields from the entire filter criteria as mentioned above and
view must be customizable, including sorting and grouping (refer to Service Requirement Document
for “GUI & Usability”).
262
263
264
265
266
4.4
267
4.4.1 AAA IN BUSINESS CONTINGENCY
268
269
MANAGE AAA POSTPONE MODE
In a situation where the XYZ application is facing technical difficulties or is unavailable for an
extended period of time, the ABC solution must have the ability for operators to manually update
Page 12 of 18
Service Requirement
270
271
272
273
274
275
276
the configuration such that AAAAs would be processed further in the normal flow without having to
wait for a XYZ R. This is to avoid processing being stopped.
 GUI Requirement - The ABC solution must have a GUI to configure the ‘Postpone AAA
Mode’, depending upon the following parameters in a mutually exclusive manner:
 Direction of AAAA i.e. Inbound/Outbound
 Country code (taken from 5th & 6th characters of Placateer BIC (for FIN) or Requestor

278
For those AAAAs that have received a “Hold” R, they must stay where they are until they are
manually released (refer to 4.3)
279
When AAA Mode is “off”, the vanilla flow according to business rules must be followed.
277
280
281
282
4.4.2 MOCKUPS
The following is a graphical representation of the requirements related to management of Postpone
AAA Mode:
283
284
Direction  Enable “Direction” screen:
285
286
The above screen must be configurable based on number of countries.
287
Currency  Enable “SSS” screen:
Page 13 of 18
Service Requirement
288
289
The above screen must be configurable based on number of.
290
XYZ Instance  Enable “XYZ Instance” screen:
291
292
293
The above screen must be configurable based on number of XYZ instances.
294
295
Note: When enabling ‘AAA Mode for a particular attribute, all selected entries within the sub screen must be
automatically deselected (i.e. no caching of previous configurations).
296
4.4.3 RISK ASSESSMENT
The requirements for the AAA Mode are critical. If they are not fully met in case XYZ is not available
for extended period of time, it would result with an interruption to AAAA processing.
297
298
299
SPECIFIC NON-FUNCTIONAL REQUIREMENTS
300
5.
301
302
No specific nonfunctional requirements for this L2 service. (refer to Service Requirement Document for).
303
6.
304
The requirements of this service have impacts on the requirements of other services which are listed
below (full list to be confirmed) :
305
IMPACT ON OTHER SERVICES
Page 14 of 18
Service Requirement


306
307
GUI & Usability
Legal Archiving
308
RISK ASSESSMENT
309
7.
310
311
312
313
314
315
316
317
If the requirements of the service ‘AAA Support’ are not fully met, the following is the impact:
 The BOLD processing would not be in compliance with regulatory & org internal compliance
guidelines
 org are at risk of placateing AAAAs to or from a TTT member who is prohibited or not advised
 Risk of reputation & loss
 Risk
318
8.
319
8.1
320
8.1.1 LIST OF BOLDS WITH AAA REQUIREMENT
APPENDIX
321
322
323
324
325
FILE ATTACHMENTS
The attached is a list of org’s internal compliance guidelines, and must be treated with strict
confidentiality. The rules do not form functional requirements, but are an example of how org plans to
configure the business rules in the AAA context.
New Text Document.txt
8.1.2 XYZ AA INTERFACE DOCUMENT
326
327
8.2
OTHER
328
8.2.1 TECHNICAL DETAILS
329
8.2.2 TTT DD WORKFLOW
330
In the TTT Inbound flow, AAA is done after Management (refer to Service Requirement Document).
331
snapshot of AAA flows to be added once the TTT workflow is created and approved.
332
8.2.3 TTT SS WORKFLOW
Page 15 of 18
Service Requirement
333
In the TTT Outbound, the AAA is done before the Management (refer to Service Requirement).
334
Adonis snapshot of AAA flows to be added once the TTT workflow is created and approved.
335
8.2.4 CURRENT AAAA FLOW BETWEEN GGG AND XYZ
336
The below is provide as a reference only, and should not be used as “To-Be” requirements
337
338
339
340
The following diagram shows the existing implementation within GGG of the Cover specific logic. It is provided for
information only as requirements in this document describe functionality that will allow ORG to configure such a
workflow within the Business Rules.
Page 16 of 18
Service Requirement
341
342
8.2.5 SAMPLE AAA TABLE
343
Listed below is the list of columns, which are present in the AAA Table of current solution at org. In the
new ABC Solution also org may look at replicating a similar solution for selecting AAAAs for AAA.
344
346
As specified in earlier chapter, org must to have access to all fields in Header (refer to Service
Requirement Document for “Supplementary Data”) and BOLD body in order to make a decision.
347
AAA Table:
345
348
349
1. Originating Application Interface
2. Originating Application Short Name
350
351
352
8.2.6 SAMPLE SET CRITERIA TABLE
Page 17 of 18
Service Requirement
355
Listed below are the columns, which are present in the Criteria table which is used for assigning Criteria
set and location ID to AAAAs, which are selected for AAA. In the new ABC Solution also org might look at
replicating the similar solution.
356
Set AAA Criteria Table:
353
354
357

Direction
Page 18 of 18