Welcome to this session on Open Financial Service.

OFS10.Versions and OFS–R13 1

 In this session, you will learn how to set OFS to handle situations such as overrides,
errors & existing NAU records that may be encountered while inputting a request.

OFS10.Versions and OFS–R13 2

 At the end of this session you should be able to
Describe GTS Control and it’s effect on OFS
Describe NAU processing and it’s effect on OFS

OFS10.Versions and OFS–R13 3

 Let’s assume the account officer in the bank has put through a Funds Transfer.
Normally, if the debit account had insufficient funds what would happen? Yes, an
override would be generated and would have to be accepted by the user for the
transaction to be completed. Now, what happens if all this was happening through
OFS? What should be done about the override?

GTS Control tells OFS what action to take if an OVERRIDE or ERROR is

encountered. GTS Control may be specified in the Version or at the
VERSION.CONTROL level. GTS control may also be specified within the OFS request
itself. If it is in the message, this value supersedes that given in the version or version
control.

OFS10.Versions and OFS–R13 4

 What can we do if an override is encountered? Either approve it or place the message
on hold so that it may approved manually later.
What can we do if an error is encountered? Either reject the message or place the
message on hold. The errors mentioned here are data errors, where though the
message is syntactically correct, errors in the data prevent it from been processed.
GTS Control permits 5 values which give you various combinations of these two sets
of actions.
When no value is specified in this field, validation errors will result in the message (i.e.
transaction) being rejected, and response returned with details of the error message. A
message which results in an override however has the override accepted, and
transaction committed.
When a value of 1 is specified, a transaction record which results in a data validation
error is put in the unauthorised file with status set to hold. A message which results in
an override has the override accepted, and transaction committed.
When a value of 2 is specified in this field, data validation errors will result in the
message being rejected, and response returned with details of the error message. A
transaction which results in an override is written into the unauthorized file with status
set to hold.
When a value of 3 is specified in this field, data validation errors will result in the
message being rejected, and response returned with details of the error message. A
transaction which results in an override is written into the unauthorized file with status
set to hold
The value 4 tells OFS to write all transactions into the unauthorized file with status set
to hold.

OFS10.Versions and OFS–R13 5

OFS10.Versions and OFS–R13 5
 As you may recall GTS.CONTROL is the 4th sub-part in the Options portion of a OFS request.
This supersedes the value given (if any) in VERSION or VERSION.CONTROL.

OFS10.Versions and OFS–R13 6

 You can see an OFS message to input a Funds Transfer and the response to that
message. This message uses a version called TEST.OVERRIDE which has 1
authoriser and null in the GTS.CONTROL field.

Note that the message is in the INAU state.

OFS10.Versions and OFS–R13 7

 Let’s set the GTS.CONTROL field in the version to 2.

OFS10.Versions and OFS–R13 8

 Try inputting the FT again.

What happened now? The record was put on Hold this time.

OFS10.Versions and OFS–R13 9

 Let’s check the record status using another OFS message. Notice that the status
shows IHLD.

OFS10.Versions and OFS–R13 10

 What happens if both the version and the message have GTS Control specified? As
you recall, the value in the version, oops, no, the value in the message supersedes
that of the version.

Here in this example the version has a GTS control of 2 , whereas the message has 1.
The status as you can see in the response shows INAU, implying that the GTS control
of the message has been used.

OFS10.Versions and OFS–R13 11

 You just saw the effect of GTS Control on a transaction with overrides. Let’s see the
effect of GTS Control on a transaction that has errors.

Here you see an OFS message which is syntactically correct. However, an attempt is
made to debit in CAD from an account that is in CHF. Since the GTS control has been
set as 1 in the message, the transaction is put on hold and the resultant record id
given back in the response. You may view the record in the INAU file.

OFS10.Versions and OFS–R13 12

OFS10.Versions and OFS–R13 13
 Here you see an OFS message for a Funds Transfer. This uses the id of the previous
FT transaction. In effect you are inputting the same transaction but with modified
values. In this case the only modified value is the amount.

What happened to the transaction? You can see that the record is in the INAU state.
i.e. it overwrote the existing record in NAU file. Now, T24 didn’t object or throw out any
warnings . If you had done this through browser you would have been warned that you
are “overtaking the work of another inputter”.

So how do you control this behaviour in OFS? Yes, use the NAU.PROCESSING field
in the version. Let’s try to do that.

OFS10.Versions and OFS–R13 14

 NAU Processing controls what happens when
A transaction is committed using OFS
An unauthorised record is formed by the application
But , the record already exists in the INAU file

The control is applied through a field in the VERSION called NAU.PROCESSING. You
cannot do this through the message as you did for GTS Control.

Obviously there are only two outcomes

a. Keep the existing NAU record, or
b. Overwrite it with the one in the OFS message

Now we know that NAU records may be created not only when we input a transaction ,
but also when we reverse an existing live record. NAU Processing addresses both.

OFS10.Versions and OFS–R13 15

 NAU.Processing can take on values 0,1,2,3 or NULL. How does the system behave
for each of these values?

0 - Reject messages when an NAU record exists

1 – This addresses an attempt to input a record which is already in the NAU state. In
this case the NAU record is overwritten with the data from the OFS message. If the
version in the OFS message is a 0 authoriser version, and the inputter in the record
and user from OFS are the same, the record is authorised. If the users are different,
the record is written to NAU but not authorised.
2 – This addresses an attempt to reverse a live record when the same record is in the
NAU file also. The existing NAU record is deleted and live record is reversed.
3 – Takes on the cumulative behaviour of 1 & 2.
Null – The behaviour depends on factors like is it a modification or reversal, no of
users, and has zero authorisation been used.

OFS10.Versions and OFS–R13 16

 Change the NAU processing field in the Funds Transfer version to 0. You can do this
by using another OFS message such as
VERSION,/I/PROCESS//0,INPUTT/123123,FUNDS.TRANSFER?TEST.O
VERRIDE,NAU.PROCESSING=0
Input a Funds Transfer with some changed amount. Ideally choose a debit account
that has a balance so that an override message is NOT raised.
Observe the result
Input the same Funds Transfer again with some changed value
Observe what happens

OFS10.Versions and OFS–R13 17

 Look at the sample message and it’s response. This shows a funds transfer from an
account that has sufficient funds. Therefore no override has been generated.

OFS10.Versions and OFS–R13 18

 Now you see the same transaction re-input with a different amount . The changes are
highlighted. You can see that the request was rejected.

OFS10.Versions and OFS–R13 19

 What happens if we set the NAU processing field to 1?

This example shows the same transaction input with a different debit amount. The
record is taken into INAU and you can see that the debit amount in the response is the
updated one.

OFS10.Versions and OFS–R13 20

 This table lists the behaviour if NAU.PROCESSING is NULL, and an attempt is made
to input a record which is already in NAU state

OFS10.Versions and OFS–R13 21

 This table lists the behaviour if NAU.PROCESSING is NULL, and an attempt is made
to reverse a record which is already in the NAU file.

OFS10.Versions and OFS–R13 22

OFS10.Versions and OFS–R13 23
 1. Bank Z uses T24 . The Funds Transfer module for various reasons still runs on a
legacy application. The transactions from this is uploaded in a batch mode to T24.
However, messages with errors must be put on hold and those with overrides
must be automatically approved. What value will you give in GTS Control?
2. The bank wants to control NAU processing in the message. What parameter
should they change?
3. You see a -2 success/failure value in your OFS response when you input a LD.
You are using a version. What field (pertaining to OFS) will you check?

OFS10.Versions and OFS–R13 24

 You should now be able to
Describe GTS Control and it’s effect on OFS
Describe NAU processing and it’s effect on OFS

OFS10.Versions and OFS–R13 26