T24 ARC Internet Banking:

TEMENOS ARC represents a strategic move to expand and consolidate our front office capabilities. ARC
will address the core client facing aspects of banking by offering dedicated delivery facades built on a
generic channel delivery interface. ARC Internet Banking is the first such channel to be implemented.

ARC-IB allows end users, ie- customers, to access their account information through the internet as well
as perform some transactions . It offers secure access using a two Factor Authentication mechanism. The
technology used is the same as that of browser. This course covers installing, configuring, using and
customising ARC-IB. Click the tabs on your left to view the course introduction, objectives and structure.

Course Introduction:

“ARC-IB” is a self-paced learning course. This course is recommended for anyone who wishes to learn
about the new Internet Banking solution for T24. Learners are expected to have undergone the
Introduction to T24 Course and Temenos Connectors Course.

“ARC Internet Banking” is an audio-enabled course. Please keep your speakers switched on to optimize
your learning experience. You may click the Notes button on the left pane to view the course notes.

Course Objectives:

In this course, you will learn how to install, configure, use and customise ARC-IB.

After completing this course, you will be able to:

 Describe the features of ARC-IB

 Compare ARC-IB and TIB

 Create an Arrangement
 Create an Internet user

 Configure the ARC-IB browser

 List and explain ARC-IB security features

 Modify ARC-IB menus and pages

 Create Daily limits

 Create a beneficiary

 Use beneficiaries in transactions

Course Structure:

The course is divided into seven learning units, each comprising of simple, self- contained topics.
Concepts are explained using simple animations and demos. At the end of each learning unit, you will be
presented with a small quiz. You will receive immediate feedback on your responses to assess your level
of understanding.
T24 ARC Internet Banking:

TEMENOS ARC represents a strategic move to expand and consolidate our front office capabilities. ARC
will address the core client facing aspects of banking by offering dedicated delivery facades built on a
generic channel delivery interface. ARC Internet Banking is the first such channel to be implemented.

ARC-IB allows end users, ie- customers, to access their account information through the internet as well
as perform some transactions . It offers secure access using a two Factor Authentication mechanism. The
technology used is the same as that of browser. This course covers installing, configuring, using and
customising ARC-IB. Click the tabs on your left to view the course introduction, objectives and structure.

Course Introduction:

“ARC-IB” is a self-paced learning course. This course is recommended for anyone who wishes to learn
about the new Internet Banking solution for T24. Learners are expected to have undergone the
Introduction to T24 Course and Temenos Connectors Course.
“ARC Internet Banking” is an audio-enabled course. Please keep your speakers switched on to optimize
your learning experience. You may click the Notes button on the left pane to view the course notes.

Course Objectives:

In this course, you will learn how to install, configure, use and customise ARC-IB.

After completing this course, you will be able to:

 Describe the features of ARC-IB

 Compare ARC-IB and TIB

 Create an Arrangement

 Create an Internet user

 Configure the ARC-IB browser

 List and explain ARC-IB security features

 Modify ARC-IB menus and pages

 Create Daily limits

 Create a beneficiary
 Use beneficiaries in transactions

Course Structure:

The course is divided into seven learning units, each comprising of simple, self- contained topics.
Concepts are explained using simple animations and demos. At the end of each learning unit, you will be
presented with a small quiz. You will receive immediate feedback on your responses to assess your level
of understanding.

T24 ARC Internet Banking:

TEMENOS ARC represents a strategic move to expand and consolidate our front office capabilities. ARC
will address the core client facing aspects of banking by offering dedicated delivery facades built on a
generic channel delivery interface. ARC Internet Banking is the first such channel to be implemented.

ARC-IB allows end users, ie- customers, to access their account information through the internet as well
as perform some transactions . It offers secure access using a two Factor Authentication mechanism. The
technology used is the same as that of browser. This course covers installing, configuring, using and
customising ARC-IB. Click the tabs on your left to view the course introduction, objectives and structure.

Course Introduction:

“ARC-IB” is a self-paced learning course. This course is recommended for anyone who wishes to learn
about the new Internet Banking solution for T24. Learners are expected to have undergone the
Introduction to T24 Course and Temenos Connectors Course.

“ARC Internet Banking” is an audio-enabled course. Please keep your speakers switched on to optimize
your learning experience. You may click the Notes button on the left pane to view the course notes.

Course Objectives:
In this course, you will learn how to install, configure, use and customise ARC-IB.

After completing this course, you will be able to:

 Describe the features of ARC-IB

 Compare ARC-IB and TIB

 Create an Arrangement

 Create an Internet user

 Configure the ARC-IB browser

 List and explain ARC-IB security features

 Modify ARC-IB menus and pages

 Create Daily limits

 Create a beneficiary

 Use beneficiaries in transactions

Course Structure:

The course is divided into seven learning units, each comprising of simple, self- contained topics.
Concepts are explained using simple animations and demos. At the end of each learning unit, you will be
presented with a small quiz. You will receive immediate feedback on your responses to assess your level
of understanding.

Welcome to this programme on ARC Internet Banking. You will learn how to install, configure and
customise Temenos ARC Internet Banking product in this programme.
You will see what is the need for ARC-IB in this first session.

We normally think of T24 users as been employees of a bank accessing T24 using the network facilities
enabled by the bank. We realised that T24 needs to communicate with other software systems in the
bank.

We came out with OFS and subsequently TCS to allow other systems to communicate with T24. We
need to provide access to other types of users, such as Home users (the actual customers) and Call
centers.

We need to provide different channels of access such as Internet, IVR etc. We need to cater to users
who are differently abled. And above all we need to provide secure access for transactions.
ARC is Temenos initiative to expand our front office capabilities and provide different channels of access.

We will take a quick look at ARC and some of the philosophies behind it before moving onto the main
aspect of the programme, i.e ARC-IB.
Typically in most banking systems, we have a kind of ‘spaghetti’ integration where each channel
accesses each module separately.

For instance , the manner in which a user was connected to the core banking module to access his
account details through the net was different from the way the same user accessed his account at a
branch.

Imagine this scenario replicating for each channel and each module. What do we end up with?
SPAGHETTI connections.

 TEMENOS ARC represents a strategic move to expand and consolidate our front office capabilities

 ARC will address the core client facing aspects of banking by offering dedicated delivery facades built
on a generic channel delivery interface

 Operational and analytical CRM features will act as the common communication layer for the client
with direct links to product marketing to maximise cross and up sell opportunities
 An orchestration layer will provide a mechanism for building consistent workflows across all channels
and managing processes and workloads within the bank

ARC-IB is the first of Temenos new generation channel banking products.

The Key Strategic objective behind Channel Banking.

To provide a fully integrated user configurable channel architecture with secure real time access to T24’s
24x7 core banking platform and its full range of transactions and data with the smallest technology
footprint possible.

A brief mention of TIB would help us appreciate the reasons as to why ARC-IB was developed. TIB (or
Temenos Internet Banking) was built on a proprietary platform called jWB (jBase Web Builder).

There are approx 30 sites live. Since the base TIB product did not have a great deal of functionality built
in, many banks carried out considerable local development to cater to their requirements.

Most of these changes were not brought back into the TIB core as a result of which support and
maintainability of the product was difficult.
These were the points considered while taking the decision to discontinue TIB:

a. Channel database was against ARC principles – TIB had it’s own channels database containing user
and access control info

b. Business functionality in front-end was against ARC principles – business functionality such as
Beneficiary support resided in TIB

c. Considerable re-architecting and development required to bring up to latest security, accessibility and
cross-platform requirements – Remember TIB was built primarily on a IIS server

d. Adding functionality required configuration in T24 and coding front end view – ie- let us say you
wanted a report on the customers. You had to create an enquiry to extract the data from T24 AND write
code in the jWB way to display the results
e. Number of live sites sufficiently small and functionality of new product sufficiently wide to enable
upgrading all of them so that only one product to support - Currently the number of sites (~30) was
considered small enough to justify the switch over to ARCIB

f. Off-line working no longer required with T24 non-stop – TIB was built originally for Globus. Since
Globus did not support non-stop processing, data was cached to ensure that customers got access to
their accounts even if Globus was offline

These were the High Level requirements for ARC-IB:

1. Produce an internet banking solution as part of ARC channel philosophy

2. The solution must be usable by our customer’s customers

a. i.e. the customers of a bank, from home (in contrast to the workers of a bank in a controlled
environment)
3. The solution must be simple to use

4. The solution must be secure and must give users confidence that it is secure

5. The solution must allow branding by the bank – i.e. bank should be able to substitute with it’s own
logo’s, static pages, static text such as terms and conditions quite easily

6. The solution must support personal, corporate and intermediary banking requirements

7. The solution must expose T24 versions, enquiries, composite screens to allow banks to customise
functionality – i.e. solution must standard T24 ways to cull out and display data. This would ensure that
the product is easily customisable and maintainable

ARC-IB unlike the older Temenos Internet banking products could be used from three different user
contexts,

Personal Banking:
The user himself was the customer. The Personal Banking product is primarily configured for retail
banking.

Intermediary Banking:

The user would act on behalf of many customers. For eg, IFAs or Bank Help Desk personnel, who need
access to several customer accounts.

Corporate Banking:

A customer would be a commercial entity. Multiple users would access the customer account, such as in
the case of a company account where perhaps the Finance Director, Finance Manager and Accounts
Officer may all need to access the company accounts. Each user could have different access rights. This
would also have facilities such as payment file upload and mandates.
You can see the Delivery map for ARC-IB in this slide.

Personal and Intermediary Banking are available with the R8 Model Bank releases. New core
applications added are AA Internet Services, AA Proxy Services, Beneficiary and EB.Secure.Message.

Corporate Banking is supported in the R9 Model Bank release. Some of the enhancements are
transaction signing, support for WebSphere (as opposed to support for Tomcat only previously) and
multiple login methods. A T24 core application called EB.MANDATE has been added.
If you look at the ARC-IB architecture from a communication viewpoint, an internet user connects to
T24 using the same technology as an internal user of the bank. Of course, exposing the T24 servers to
the internet means you need to put in a lot of security - yes, that’s right, the security angle. So we put in
firewalls and reverse proxies to shield our T24 server from the bad guys.

So then how do we know who is getting into T24? Good guy or bad guy? Right, we need authentication.
We put in an authentication server and a HSM (Hardware Security Module) to make sure that the right
people get access. We will take a closer look at authentication later.

And finally we replicate the tiers to provide scalability and fault tolerance.
But the bottom line is:

The way that an internet user and a internal user connect and use T24 is the same.

An internet user uses standard T24 versions, enquiries, menus, composite pages like an internal user.

It is the way that the browser in between is configured that makes the difference.
Well then, what do we need to setup ARC-IB? To setup ARC IB, you will need

1. A T24 area

a. This must be release Model Bank R08 or higher. To check Corporate functionality you need Model
Bank R09

b. Since ARC-IB uses AA, the products AA & AI must be enabled in the SPF and COMPANY

c. AP is also needed for Intermediary and Corporate banking

2. You will need the browser war file for ARC-IB. This may be downloaded from the Knowledgebase
ARC IB makes extensive use of Composite Pages. These pages uses AJAX (Asynchronous Java with XML)
technology.

The logo is actually an HTML fragment.

The menu at the top is just a standard HTML menu.

And the best for the last - The rest of the composite is just standard enquiries and versions.

The menu in the middle is generated using HELPTEXT.MENU . It is displayed in a tabbed format by
default as against a hierarchical tree in the standard browser.
ARC-IB is implemented as enhancements to T24. These consist of:

An application to store external user details:

 EB.EXTERNAL.USER

The AA product Builder has the supporting product lines:

 INTERNET.SERVICES and PROXY.SERVICES

A place to define your channel:

 EB.CHANNEL

Some new business functionality:

 DAILY LIMITS

 BENEFICIARY

 FT enhancement (Beneficiary support)

 EB.MANDATE

Some other new applications:

 EB.SECURE.MESSAGE

Enhancements to standard T24 applications:

 ENQUIRY enhancements

 VERSION enhancements (Context flow)

 SMS enhancements (!CURRENT.VARIABLE support)

EB.COMPOSITE.SCREEN (frameless support)

Other changes are:

Use of an external authentication server:

 2 factor authentication

Major enhancements to Browser primarily through the use of AJAX. This allows us to move away from
frames. The advantages are:

Improved security:

 Protection against Frame attacks

Improved user experience:

 Better sizing of components

 Partial page reloads

Use of ‘fragments’:

 Sub divide the page according to Composite Screen specification

 Each fragment is an HTML <div> element

 Fragments are updated independently

After completing this learning unit, you will be able to:

 Explain Arrangement Architecture

 Describe the components of a Product

 Explain the Product Lifecycle

Note:

The purpose of this unit is not to provide a detailed study of AA but rather to provide an overview, so
that participants will be able to use the relevant functionality for ARC IB.
1. What is an Arrangement? The normal definition of an arrangement is “an agreement between
involved parties”

2. Some examples of arrangements are:

 account – a financial instrument agreement between a customer and a bank (e.g. mortgage, deposit,
etc.)

 terms and conditions – a usage agreement between a customer and a bank (e.g. internet services)

 user profile – an agreement between a user and a bank detailing usage of a system (e.g. USER and
SMS)
1. What then is a framework? The general definition of a Framework is “a basic conceptual structure” or
a “skeletal, openwork or structural frame”

2. What does a framework imply within a software context? A framework is “a reusable design for a
software system (or subsystem)”. It is often expressed as a set of abstract classes and the way their
instances collaborate for a specific type of software. A software framework may include support
programs, code libraries, a scripting language, or other software to help develop and glue together the
different components of a software project
Within the context of AA, an arrangement is an instance of a product or service associated with a
customer.

For e.g.

a. An Internet Services Arrangement defines the user profile for an internet user
b. A Deposits Arrangement defines the deposit conditions for a customer holding a deposit account

1. You define and service Products using AA

2. A list of products that have been defined by the bank are maintained in a Product Catalogue

3. The Product Builder allows you to design, proof and publish to the Product Catologue

Initially Product Builder is targeted at retail products such as lending, deposits, savings & current a/c,
internet banking. Each product is made up of a set of fundamental business components. You will see
about these fundamental business components later.
The fundamental business components are property classes and properties,
1. Property classes are re-usable business components. There are many such components defined by
Temenos. Some of them are Protection limit, Interest, Charges, Payment Schedule, UI Behaviour, UI
Appearance and Product Access

2. A Property is a named type of a Property Class

You could compare this to Object Oriented concepts where a Property class serves as a class definition
and a property is an instance of that class.

Examples of property classes are:

 Term Amount

 Interest

 Payment Schedule
 Charges

Examples of property classes used within an Internet Services arrangement are:

 Customer

 Arrangement Preferences

 User rights

 Product Access

 Protection limits

 UI Behaviour

 UI Appearance
1. To facilitate the creating of products you use Product Lines and Product Groups. As discussed earlier,
there may be many different business components forming a product. Some components may be
reusable across different products. Eg- Customer, Limit, Activity API. Some may be peculiar to a product.
Eg – UI Behavior, UI Appearance are valid for a Internet Banking product. A Product Line, which is
defined by Temenos, helps group the property classes relevant to that particular product line. Some of
them may be mandatory; some optional

2. A Product Group helps refine a Product Line further. It allows you to define the named Properties for
that group. You may also mark certain properties as mandatory, in addition to those defined as
mandatory at the product line level. An Internet Services Product Group is often referred to as a Class of
Service

3. A Product is defined by specifying the Product Conditions for its properties

The Internet Services Product Line features are divided into components, and implemented through
Property Classes.

Customer:

Every Arrangement is associated with a Primary Owner (i.e. customer).

Arrangement Preferences:

This property class specifies the arrangement to be used and the primary account if any. This is not
functional currently.

User rights:

Specifies the SMS settings for a user – particularly the SMS group that this user belongs to.

Product Access:

Used to limit access to certain accounts, arrangements and portfolios. This is not functional in R9 GA.
Protection Limits:

Protection limit sets a daily limit on the transactions made by a internet user. This is not the same as
Limits.

UI Behavior:

Allows us to control the browser behaviour . For instance, do we allow hotfields? Or Context enquiries?
What is the first composite page that the user sees?

UI Appearance:

This property class allows us to specify the UI appearance – skin, date format , amount format and
language.

The last three property classes Activity Presentation , Activity Messaging and Activity API are common
for all Product Lines.
A product is made up of properties. The possible properties that may be used to define a product are
specified within a Product Group. A Product Group may not use properties outside of it’s product line.

Some property classes must mandatorily be included in a Product Group. An Internet Services Product
Group must include properties for the following property classes;

a. Customer

b. User Rights

c. UI Behaviour

d. UI Appearance

Protection Limit is optional. Product Access and Arrangement Preferences are not functional yet.
There may multiple instances, i.e.- properties defined, per property class.

Let us consider the NetBanking Product Group shown in this example. This may contain:

1. A named property called Customer of the Property Class called Customer

2. A named property called Daily Limits pertaining to the property class Protection Limits

3. Named properties called Standard and Premium of the Property Class UI Behaviour

4. Named properties called Standard and Premium of the Property Class UI Appearance. And so on.

You design a Product using the Product Designer. A product comprises of properties and product
conditions. Product conditions allow you to define the parameters and default values for an
arrangement. Some of these default values may be modified (negotiated) at the arrangement level. You
can control the negotiation parameter for each product condition.
The screen shot here shows a Product Condition for Protection Limit. This property class, if you recall,
sets the daily transaction limit for a internet user. This example shows a daily limit of USD 10,000.

You can set Negotiation Rules for most product conditions. The negotiation rules set boundaries on the
changes made to an attribute while creating an arrangement. Look at the screen shot in the slide.
This shows that the attribute LIMIT.AMOUNT may be NEGOTIABLE (i.e.-changed while creating an
arrangement) to the MAXIMUM limit of 20000. Any change beyond this limit will result in a OVERRIDE.

a. Attribute - an attribute specified under the default values tab

b. Options - Could be FIX-VALUE/MANDATORY/NEGOTIABLE/NON-NEGOTIABLE/OVERRIDE

c. Type - Various options : Eg: MAXIMUM/MINIMUM/RANGE/EQUAL/LIKE

d. Value - value matching the attribute’s data

e. Message - Could be OVERRIDE/ERROR. ie. The manner in which deviations from the negotiation rules
should be handled

Let’s summarise:
a. Temenos defines various Product Lines. A Product Line comprises of Property Classes. Each property
class contains attributes

b. Product Groups is a subset of a Product Line. It contains named instances of property classes called
properties

c. A Product is derived from a Product Group. It may contain all or some of the properties of the
product group. Products also use Product Conditions which allow you to allocate specific default values
for each property

A product must be proofed and published before it becomes ready for use. You do this using the Product
Manager. Remember a product has a effective date also.
Create:

Product Designer allows you to create products with their properties and conditions. From this point
forward, the financial institution controls the lifecycle of the product using the Product Manager.

Proof:

The next stage is Proofing. At the proofing stage, you need to set the available date of the product. This
will allow you to enter the product into the catalog in advance of it going on sale. Proofing validates that
the product has been configured correctly, and is ready for release. Proofing includes for example
checking whether all mandatory properties have been given conditions, that there are no conflicts
between those conditions, and any other errors that would prevent the product being published.

Fix:

Any errors generated can be fixed by going back to the Product Designer, and then re-proofing the
product.

Publish:
When the product is published, it is entered into the Product Catalog, which is the tool used to actually
create Arrangements.

Modify:

Once published, products can be modified at any time. Modification is done in the Product Designer,
using the same method as for creation. Modifications will only appear in the Product Catalog once the
proofing & publishing process has been repeated.

An arrangement is an instance of a product associated with a customer. Creating an arrangement

involves “negotiating” with the customer changes to the standard product specification. Technically the
arrangement is created with a copy of the product conditions, some of which can then be modified, and
some cannot.
Lets summarise. AA uses fundamental business components called property classes.

1. Product Lines group a set of property classes

2. A Product Group allows you to define the named Properties for that group. Properties are named
instances of Property Classes

3. A Product is defined by specifying the Product Conditions for its Properties

4. An Arrangement is created with arrangement conditions. Arrangement Conditions may be derived

from the Product Conditions
1. An Arrangement is a Product associated with a Customer

2. A Product is composed of Product Conditions and Properties

3. Properties are named instances of Property Classes

4. Product Lines group Property classes related to a specific functionality such as Internet Services,
Accounts, Deposits

5. Product Lines are defined by Temenos

6. Product Groups allow us (or the bank) to group Properties together

7. A Product must Proofed and Published before it can be used

8. Products are defined using the Product Builder
We will be setting up the following:

 EB.CHANNEL
 Generic ARC IB User

 OFS.SOURCE

 tcserver.xml

 Browser WAR file (ARC IB)

 channels.xml

 INTERNET.SERVICES Arrangement - this is something we need to do through AA. We will discuss AA

and INTERNET.SERVICES as we go on

EB.EXTERNAL.USER

The following are optional and are required only for testing/training purposes:

 Customer - a sample CUSTOMER

 Account x2 - two sample account records for the customer, with at least one of them having a balance

 FT - You probably need an account with a balance, so it would be a good idea to transfer some money
The browser.war file used for normal (internal) browser deployment and the one used for an Internet
Banking deployment are the same in terms of the code that they use. They are packaged and configured
differently.
The TCS configuration as specified in tcserver.xml is very similar to the normal tcserver configuration. It
is the parameter ARC-IB, i.e. content of the OFS.SOURCE record ARCIB, which is used instead of GCS,
that makes this adapter function differently. You may ask, “What is the difference”? Well, not much. We
will look at that in a moment.

Notice the parameter value ARC-IB instead of BROWSER in browserParameters.xml. Is there anything
else different in the configuration of this war file as compared to the standard browser war file?
Nothing!
Some differences here - for security purposes. Remember this browser web application is going to be
accessed over the internet and not via a controlled intranet within the bank.

The JavaScript that is used finally on the browser client is obfuscated for Internet users. This is to
prevent hackers from modifying the script to gain additional privileges. Of course, a properly configured
SMS should stop the hacker from further mischief but.
Let us now look at configuring R9 for ARC-IB:

1. All connections to R9 are through the jbase_agent

2. Jbase_agent is part of TAFC. It is primarily a non-blocking socket listener

3. The port to be used can be specified with a -p parameter

4. For example, you can type jbase_agent -p 9494 to cause the agent listen on port 9494

5. Absence of this parameter would cause the agent to listen on port 20001

6. How does jbase_agent know which area to connect to ? Simple! You start it from the .run folder of
your area
Let us now see how to configure ARB-IB war files in TOCF. TOCF requires the use of an application server
such as JBoss. You need to ensure that the following files are present in the deploy folder:

 jremote-ra.rar

 t24-ds.xml

Note :

The deploy folder for jboss is server\default\deploy.

Jremote is the client side component of jbase_agent. You can compare jbase_agent to TCS and jremote
to TCC.

Jremote is deployed in an application server such as Jboss.

Jremote sends messages to jbase_agent through the designated port.

The port (and other parameters) are specified in a configuration file called t24-ds.xml.
A connection factory may be compared to a channel. It specifies the connection parameters.

Jndi-name used to relate to the war file.

Rar-name specifies the rar file to be used for this connection.

Config-property host specifies the IP address of the host, i.e the machine hosting the jbase_agent and
T24 area.

Config-property port specifies the port number to send messages to. Obviously this must the port
number used by the jbase agent.

Config-property env specifes the OFS.SOURCE record id.

Now let us see how to configure the ARC-IB war file in R9 with TOCF(EE):

1. The war file may be deployed as it is inside the server\default\deploy directory of Jboss

2. However, it is better to extract and use the folder inside the deployed directory, as this makes it
easier to change the configuration files

3. The exploded folder must have a .war extension

4. Make sure that you have either the war file or the folder in the deploy directory
You can see the changes in browserParameters.xml for ARC-IB in the screenshot. The product used here
is still ARC-IB. However, a new Server Connection Method, i.e. AGENT has been specified.

What about browserConnection and channels? These are not used in TOCF, i.e if the server connection
method is AGENT.

Let us look at the OFS.SOURCE record next.

Well, what is it that makes this record different from a standard OFS.SOURCE record like GCS or
BROWSERTC? The use of the CHANNEL field. This field contains a reference to a record in EB.CHANNEL.

The OFS.SOURCE record must be of type SESSION. Syntax type should ideally be XML. (Syntax type OFS
works too as the screenshot in the slide shows).
Make sure that you have a valid generic USER. This shows the sample ARCUSER profile that is used for
the Generic User.
Temenos recommends that the generic user should be setup with minimum functionality.

To do this you need to:

a. Disable menus: give the id of a nonexistent menu in Init Application

b. Grant minimal user rights to applications: e.g.- give View access to a single application say
EB.CHANNEL

c. Disable command line, user menus, list of enquiries, reports on desktop: Specify LOCK.MISC.ITEMS in
Attributes
A CUSTOMER who wishes to access T24 through the internet needs to have:

a. A CUSTOMER id
b. An arrangement

c. A external user login id - recorded in EB.EXTERNAL.USER

An arrangement is created using AA. You use a product (which we should have defined) from a specific
product line called INTERNET.SERVICEs to create the arrangement. The arrangement helps put together
the customer profile consisting of parameters such as the access rights of the customer, the kind of UI
that he or she gets, the daily limits on the transactions carried out by the customer etc. Stated simply,
the profile for the customer is setup using an Internet Services Arrangement. The profile is linked to an
external user id in an application called EB.EXTERNAL.USER.

We will next see how to create an Internet Services Arrangement.

You will create our own arrangement and use this to create an Internet Banking User. Click on the MB
Admin Menu -> Internet Banking Administration -> New Internet Services Arrangement.

 
Note - We assume that ARC-IB Product Groups and Products have already been setup in the Model
Bank Demo database.

You choose the Model Personal product. Remember an arrangement associates a customer with a
product. The list of products that are shown may vary depending on the demo database installed in your
system.
Arrangements are created through activities. The Id that you see at the top of the screen is NOT the id of
the arrangement but the id of the activity that creates the arrangement. Note the prefix AAACT denoting
AA Activity.
The Arrangement parameters are shown, with default values populated by the Product Conditions.
These values may be changed. Whether they can be changed and the boundaries for those changes
depend on arrangement links and negotiation rules. For this example, you will not make any changes
initially.

More arrangement parameters - for Daily Protection limits and UI.Appearance.

More arrangement parameters - for UI.Behaviour.

You must remember that you are committing the activity that creates the arrangement. The Id shown is
the activity id, and not the arrangement id. The arrangement id is shown as a field within the activity
record.
 

What next? Simple -You Authorise the Arrangement Activity.

Unfortunately, the Arrangements link is not under the Product Builder or Internet Banking menus in MB
R08. It is under MB User Menu-> Credit Operations ->Loans -> Retail Lending.
You could make navigation easier, by adding the authorise menu to the standard AA Admin menus. To
do so, add the command COS AA.ARRANGEMENT to the HELPTEXT.MENU record MB.AI.ADMIN.MENU
as shown.

EB.EXTERNAL.USER links the external customer id to his/her user profile (i.e. - the arrangement). You
will see how to create an external user id.
Click on the New External User menu under the Internet Banking Service Arrangement.

Enter a new external user id.

a. Customer Number: specify the customer number for the user

b. Internet Services Arrangement: specify the arrangement

c. Access start date/ End date: the valid access dates for the user

d. Password Review Frequency: standard password review frequency

Note - this password review frequency should be set as large as possible. The external user would
normally not use this password directly but rather would use an id and PIN that would be validated by
the authentication server. Hence there is no need to reset this frequently. We will discuss this in the
chapter on ARC-IB Security later.

The following changes have been made to EB.EXTERNAL.USER in R9:

1. The Channel Type field in EB.EXTERNAL.USER has been changed to CHANNEL

2. You can now specify multiple login methods in EB.EXTERNAL.USER through the field LOGIN.METHOD.
It supports login methods such OTP(One Time Password), OTP & PIN (OTP and Personal Identification
Numer), PW (Password), PW & MW (Password and Memorable Word).These login methods are
supported by 4TRESS authentication only currently

3. Authentication type: This field can contain the value USER.MAINTAINED or EXTERNAL. When the
value of this field is USER.MAINTAINED, ARC-IB maintains a user id and password. This is provided
primarily for demo purpose. EXTERNAL is specified where ARC-IB uses an external authentication server.
The user id and password for Internet banking would be maintained by the authentication server

1. Load the ARC-IB browser

2. Enter the uid (e.g.: ROBINHOOD) and the password(This password can be any 6 digit character).

3. You should get a welcome page similar to what is shown here

Note - new releases of ARC-IB allow you to use the memorable word as the password.
So far you have created an Internet Services arrangement. The arrangement comprised of properties
and conditions pertaining to the following property classes:

1. Customer

2. User Rights

3. UI Appearance

4. UI Behaviour

5. Product Access (which was optional)

6. Arrangement Preferences
7. Protection Limit (which is also optional)

You used this arrangement and an existing Customer id to create a record in the EB.EXTERNAL.USER
table.

You invoke the Product Designer by using MBAdmin Menu -> Product Builder -> Products menu.

Note - the screen shot shows the Product Designer with the Product Line for Internet Services expanded
to show the Product group and Products.
Click on the View or Amend Description icons to see the property classes that belong to a product line.
Remember, property classes themselves and the group of property classes within a Product Line is
defined by Temenos. This cannot be customised.

Let’s now look at the Product Group and its Properties.

Click on the View or Amend icons to see the properties of a product group.

Note the properties specified against each property class.

CUSTOMER - CUSTOMER

PROTECTION LIMIT - DAILYLIMITS

UI APPEARANCE - UIAPPEARANCE

UI BEHAVIOUR - UIBEHAVIOUR

USER RIGHTS - USER RIGHTS

Click on the Amend or View icon to look at how a product is composed. The Property Conditions tab for
a Product displays the components of a Product. A Product as you can see is composed of Properties,
(Product) Conditions and Arrangement Links.

You will next see how Properties are created.

How were the properties created? Using the “Property Class and Properties” menu shown above. You
can see the property called CUSTOMER which relates to the property class called CUSTOMER.

Note - the property and property class may both be called the same name.
Let’s look at one more Property - Daily Limits. Properties are quite simple with just a name and a
description. Now that you have seen two properties, you will find that other properties are very much
the same. You combine Properties with Product Conditions to create Products.

You will now see how Product Conditions are created.

Click on MB Admin Menu -> Product Builder -> Product Conditions to bring the T24 Product Conditions
Browser window.

Choose a (Property) Class, say Protection Limit and look at the Product Conditions for it. Look at the
content of the Product condition by using either the view or amend links.
This shows the default parameters for CUSTOMER. This seems to be a fairly simple condition - nothing to
actually set. Well, let’s take a look at some more conditions.
This condition specifies the default parameters for UI Appearance. UI Appearance and UI Behaviour are
used in place of BROWSER.PREFERENCES to control how browser looks. UI Appearance contains the
following attributes.

Skin name - which is the skin to be used

Tool Style - i.e tool style,. - text, image or both text and image

Language - 1,2,3,4

Date Format - 1,2,3,4

Amount Format - ., or

UI Behaviour contains Contract Attributes.

These attributes enable / disable the contract features:

MULTI.VERSION.HEADERS - allows multi-line version headers to be displayed.

NO.AUTO.LAUNCHES - restricts auto launch of enquiries.

NO.CALENDAR -hides the calendar icon.

NO.CHECKFILE.ENRICHMENT - turns off the check file enrichment feature.

NO.CONTEXT.ENQUIRIES - disables the context enquiries.

NO.DROPDOWNS - disables the dropdown feature.

NO.HEADER.TAB - turns off the contract header.

NO.HOT.FIELDS - disables hot fields.

NO.WEB.VALIDATION.FIELDS - disables web validation.

Enquiry Attributes:

The Enquiry Attributes enable / disable enquiry features:

NO.SELECTION - restricts display of enquiry selection screen.

ALL.DATA - loads all the selected records.

NO.COLUMN.HEADER - restricts the column header being displayed on the enquiry results.
NO.TOOLBAR - disables the enquiry toolbar.

ZERORECORD.DISPLAY - displays blank screen when no records are selected.

Toolbars and Flow:

The toolbar and composite screens to be displayed during the first login or every login. (Flow is
discussed later).

This product condition allows you to specify default SMS settings for a user.

Attributes:

SMS Group - allows you to generically specify SMS settings for a group. Entry here must be the id of a
valid record USER.SMS.GROUP. Note the use of MB.AI.PERSONAL.
Allowed Days - allows you to specify the days in which a user may login. Some valid entries are ALL,
WORKING.DAY, WEEKDAY, MONDAY.

Start time and End time - this allows you to specify the access time. This must be a valid time in 24 hr
clock.

You will see about Allowed Customer and Proxy Arrangements later.

This Product condition allows you to set the Overall Daily limit per user.

Note - Daily limit is discussed in detail later.

You can also specify Negotiation Rules apart from default values in a condition. What are Negotiation
Rules?

Negotiation Rules lets you to set the boundaries for the parameter values while creating an
arrangement. The example shows a max limit of 20000 has been set.

Note - Most of the Product Conditions used for ARC-IB do not have Negotiation Rules.
Lets summaries what you have seen so far. You have seen that to create a Product Condition:

1. You need to specify default values for its parameters

2. You may set Negotiation Rules to control changes to the default parameters while creating an
Arrangement condition from the Product Condition

You will next try creating Product Conditions on your own.

You have seen what are the components of a product. To create a Product you need to specify its Id,
Product Group that it belongs to (this is set by default) and list out its Properties, corresponding
(Product) Conditions and Arrangement Link for each property.

What is this Arrangement Link? What does it ‘link’ together? Let us look at that next.
After creating your product and publishing it to the product catalogue, what happens if you want to
change any of the conditions? A good example is a fixed rate loan, where you want to change the
principal interest rate. In this case you want the existing Arrangements to be unaffected, while the new
ones pick up the new rate. Or alternatively, what if you want to change the terms and conditions for
overdue processing. In this case you want all the outstanding Arrangements to adopt the new
behaviour.

An Arrangement link specifies whether these changes can be made and how subsequent changes to the
product will affect them.
Each property contained in your product can have its Arrangement Link set to one of three values. Note
that in some cases the effect of the Arrangement link can be influenced by the negotiation rules, and
vice versa. So the two must be considered together. The three types of Arrangement links are

Tracking:

a. Changes to attributes at the product level will be reflected in the Arrangement

b. At the Arrangement level, all attributes are non-inputable as a result

c. Any negotiation rules will be ignored

Non-Tracking:
a. Arrangement attributes are unaffected by product-level changes

b. At the Arrangement level, Attributes can be negotiated, subject to Negotiation Rules in

corresponding Product Condition

Custom Tracking:

a. Tracking behavior can vary across attributes

b. Individual attribute behavior defined in Product Condition’s Negotiation Rules

Let us try to understand this with an example.

Any change to any of the constituent parts of a Product must be Proofed and Published for the change
as such to be recognised and accepted. Proofing recognises that a change has been made and validates
the record. After the validation, the change must be incorporated into the Product Catalogue. This is
done by Publishing.

You use the Manage icon in the Product enquiry under the Product Builder menu to do so.

Change the action to PROOF. Change the required date if required. If the required date is forward dated,
changes to the product take effect only then.

Notice the change in the version field after committing the record.
Publish the changes to the Product Catalogue by invoking the Product Manager, changing the Action
attribute to PUBLISH and committing the change.
Remember that Product Conditions specify default values and may be changed. For example we may
change the Production Condition for Protection Limit to USD 15000. However, this condition that has
been changed is not applied to the product unless the product is proofed and published.

Test out the new protection limit, by creating and authorising a new arrangement. See if the default
value for the Protection Limit has changed.
You will now check the effect of the Negotiation Rule that you set earlier. Change the limit to 30000 in
your arrangement and commit the arrangement. An override would be generated.

Explanation: An Override or Error is generated when we step outside the boundaries of a Negotiation
Rule while creating a new arrangement. Refer back to the slide on Negotiation Rules to check the
Message parameter.
 You configure ARC-IB Browser differently from internal browser

 You need an OFS.SOURCE with CHANNEL Internet

 Grant Generic user minimum rights

 You need a Customer, Arrangement and EB.EXTERNAL.USER to login through ARC-IB

 You can use properties and product conditions pertaining Customer, User Rights, UI Appearance, UI
Behaviour, Product Access, Arrangement Preferences and Protection Limit within an Internet Services
arrangement

 You use Product Designer to design Products

 You use Product Manager to Proof and Publish products

 Use UI Appearance and UI Behaviour to specify UI parameters

 Specify SMS Group in User Rights to control access

 Use Protection Limit is used to set Daily Limits for transactions

 Use Negotiation Rule to specify rules for parameter values while creating an arrangement

 Use Arrangement link to specify the link between the product default parameters and the
arrangement parameters
Two features were added to ARC-IB. They are:

a. Protection Limits
b. Beneficiaries

Protection limits allows us to set a daily limit on transactions. Beneficiaries allows a customer (internet
user) to name his/her beneficiary.
Bank can define wide range. e.g.

 Overall daily limit per user in Local Currency equivalent

 Daily limit per user on payments to high risk beneficiaries

 Daily limit per currency per user

 Daily limit per transaction type per user

This screenshot shows a daily limit 2000 USD. The allowed currency for transactions has been specified
as USD. This means that the daily limit is applicable only for transactions in USD. Transactions in other
currencies would not be affected by the limit. If the allowed Ccy field was blank, the limit would apply to
transactions in any currency.
You can see Negotiation Rules been set in this screenshot. Negotiation Rules lets you to set the
boundaries for the parameter values while creating an arrangement. Here this rule imposes a limit of
5000.

You may have questions such as,

When do limits apply?

Limits apply only when a transaction is input

What are the factors which count or don’t count?

a. Limits ignore value date

b. For recurring payments, only first payment counts towards limit

How are ‘exceptions’ handled?

a. Attempted breach of a limit displays an override which is normally mapped to an error message
b. User can amend the transaction and retry

How do we view limit usage?

The enquiry %PROTECTION.USAGE displays limit usage.

Beneficiary was available earlier as part of TIB. It has now been included as part of T24 core. Beneficiary
allows you to create your own name for an account, which may then be used while carrying out a funds
transfer or standing order. Beneficiaries could be defined by the users themselves or they could be
defined by the bank.

Some of the important fields within Beneficiary are;

Ben Account number:

You specify the actual account no here. This field could be linked to the credit account no or beneficiary
account number (BEN.ACCT.NO) field in Funds Transfers, or to the Counterparty Account Number
(CPTY.ACCT.NO) in Standing Orders.

Owning Customer:

You specify the id of the customer that owns (uses) the beneficiary. This is left blank in the case of Bank
defined beneficiaries as any customer might want to use such a beneficiary.

Risk:
Risk rating (single digit number) for each beneficiary.

Default Narrative:

Used to provide default reference text in Customer defined beneficiaries. This field is linked to Debit
their ref field in FT and STO.

Link to Beneficiary:

This field is used by User defined beneficiaries to link to a bank defined beneficiary.

You see two examples of beneficiaries above. Notice that primarily the user defined beneficiary contains
a value for the Owning Customer field.
FT has a provision of adding a beneficiary. The entry given here must match a record id in Beneficiary.
You could use a Personal Beneficiary Id in an FT. This Personal Beneficiary in turn could be linked to a
bank-defined beneficiary.
a. Use Protection limit to setup daily limits for transactions

b. Use Beneficiaries to record beneficiary details

c. Beneficiaries may be used with FT or STO

d. Beneficiary may be defined by the user or by the bank

What are the components of the ARC-IB architecture? The architecture is composed of some primary
components and security components.

Primary Components:

 Servlet container or Application Server

 T24 App Server

Security Components:

 Authentication Server

 Hardware Security Module

 Firewall
 Reverse Proxy Server

The architecture should provide for the following features:

 It should be horizontally scalable

 It should be Stateless

 Architecture must be Resilient – i.e. no single point of failure

 The Business logic should be within T24 and wherever possible, channel agnostic

 It should provide the option to secure with SSL termination

 The architecture should provide for sticky load balancing

Peak concurrent usage for Personal Banking = 0.3 – 5.0% depending on type of service and country.
Factors like does everyone get paid on the same day or Tax deadlines could affect peak concurrent
usage.

 
Business banking will be different.

Relatively easy if bank has existing Internet Banking.

Otherwise very hard.

T24 servers need to be sized for Internal + External concurrent users.

We are not experts at hardware – need to involve Bank IT department or local supplier. Typically a few
hundred concurrent users per Tomcat server.

The following factors affect the look and feel of ARC-IB:

 UI.Appearance

 UI Behaviour and Context Flow

UI.APPEARANCE defines the user interface appearance such as skin, tool style, language, date format,
amount format etc. Skin should have corresponding parameters in BrowserParameters.xml and be
supported by corresponding styles and images in your web server.
Context flow? As the words suggest the flow, i.e. - page or composite screen to be called, varies
depending on the context.

For example, the bank may wish to display a Terms and Conditions page during the first ever login of a
user, or request certain classes of users to supply their password during committal of a contract. Context
flow is dictated in the property class UI.BEHAVIOUR.

Let’s illustrate context flow with an example. We will use the sample composite screen in Model Bank
call MB.AI.MAIN.PERSONAL.This is the composite that is seen by a user when he or she signs into T24
through using the Internet Services.
We can specify an action to be performed when a user logs in for the very first time. This is done by
specifying the flow type as FIRST.LOGIN and specifying the action, i.e. the Composite or Version or
Enquiry to be called, in the flow value. How does the system know whether this is the first login or not?
Normally the login page, that a user sees the first time that he/she logins in, would be the Terms and
Conditions page. We have field called the T/C Accepted field in EB.EXTERNAL.USER that is set to yes by
the user on accepting the terms and conditions. That implies that this field must be initially set to No (or
Null) for the First Login page to be displayed.

The first login page could be a JSP or composite page. The flow type EVERY.LOGIN specifies the page to
be called during normal logins. The page or composite to be called is given in Flow Value.

The flow type field allows specifying the context and the action to be carried out in that context.

 FIRST.LOGIN

Action to be preformed when a user logs in for the very first time. This is valid only if the T/C Accepted
field in EB.EXTERNAL.USER is to set NULL/NO.

 EVERY.LOGIN

Action to be performed when a user logs in. What a user normally sees.
 INITIAL.SCREEN

The initial screen to be displayed after the EVERY.LOGIN stage. A welcome page.

 POST.COMMIT

Action to be carried out during the post contract commits stage. This is used only when the Preview
Version is not defined.

 LOGOUT

Action for post logoff.

How does context flow work? Well, we have broken down the transaction into three phases:

 Edit

 Confirm
 Preview

Each phase can use a different version.

Why do we need this? Think about what happens when you commit a transaction. Let us assume you
get an override. You accept the override. What happens next? You get a message saying transaction id
number xxxxxxxxxxx successfully committed.

The two displays that we get here might not be very meaningful to an internet banking user. The
Confirm and Preview versions allow us to present something more meaningful to the user. Additionally
it allows us to suppress important information (from the bank’s perspective) such as the transaction id.

Look at this screenshot. It shows a FT version called MB.AI.AC. It has a corresponding Confirm version
and Preview version.

This is the Confirm version for MB.AI.AC called MB.AI.AC.CONFIRM.

Note :

It is a good practice to name your versions with the appropriate suffixes.

Reference: T24 User Guides > Security > Browser Security.

Quote from Crypto Card – 2FA Authentication Whitepaper

“Authentication is the process by which you positively identify users to your network. The
authentication measures you employ essentially act as ‘gatekeeper’ to your networked assets. Password
Authentication (or more accurately ‘Static Password’), the authentication method used by
approximately 95% of the computing world, was developed decades ago and no longer provides even
basic protection. The FBI warns that static passwords are one of the biggest threats to network security
today.”

Passwords can be easily cracked. At least 24% of cybercrime losses are a result of unauthorized
access.LC4 is just one of many powerful password cracking programs that can be downloaded from
anywhere in the world free of charge.

These are some famous – or shall we say in-famous examples, when security systems were
compromised:

 40 million credit card numbers were compromised when a Visa, MasterCard and American Express
supplier (Card systems) was hacked
 Social Security Numbers and personal information belonging to 26.5 million War Veterans were
hacked

 3.9 Million Citibank customers whose debit card numbers and PINs were hacked

What are the factors we can use to authenticate?

a. Something we know

b. Something we have

c. Something we are

We are familiar with two Factor authentication. Most of us use a Debit card (something we have) along
with a PIN (something we know).
The token is a small electronic device capable of generating a random number. This number is used to
authenticate your identity along with the customary user id and password.

How do the tokens (and OTPs) work?

1. You have a token. The token generates a pseudo random number - a One Time Password

2. You send the OTP to a server (along with your user id and ‘normal’ password)

3. Server also generates a random number – matching the OTP

Temenos preferred authentication server is 4TRESS from ActivIdentity. This server supports the
following features:

 It follows Two-factor hardware token authentication as standard

a. Meets FFIEC guidelines

b. Various token types

 It supports other methods of supplying an OTP. E.g. through a mobile phone

 It can be downgraded to password and user secret (random characters)

 It allows different classes of user can have different authentication mechanisms (this feature is still to
be implemented)

 And finally the same authentication system could be made available to other channels (e.g. IVR)

Transactions may also be authenticated. ARC-IB can be configured to require OTP (TAN), password, or
user secret input to confirm or authorise a transaction. This feature is currently not available but is
planned for phase 3.
How do we setup ARC-IB to use an OTP? Apart from the token in use on the client side, we need 3
components on the server side. They are:

A third party authentication server - What is the purpose of this authentication server? This
authentication server contains a user id and password which we use to authenticate users. It maps this
set of credentials against T24 credentials. Both these credentials are stored within a secure, encrypted
data store.

The end user will only be aware of the credentials at the authentication server level and need not be
aware of the T24 level credentials. Currently we support two common products that are available in the
market, namely ActivIdentity 4TRESS and RSA Authentication Manager.

A Hardware Security Module such NCipher NetHSM or minimum a Java Key Store - What is the purpose
of an HSM? The authentication server as you saw earlier stores encrypted T24 credentials. Who does
this encryption and who has the key to perform this encryption? Well, that is the purpose of a HSM. A
java key store could be used to perform the same function, but is not as secure as a HSM.

A web server such as Tomcat - Currently Tomcat is the only java web server that can be used as this
supports the latest JAAS specification. Other web servers may be supported once they become JAAS
compliant.
The ARC-IB servlet contains JAAS compliant code. What does this code do? This code takes a login
request, which should normally be sent to the T24 App Server, and redirects it to the authentication
server.

Temenos deployment partners are ActivIdentity, RSA and Ncipher.

4TRESS features:

 4TRESS supports tokens, user id/password/memorable data

 It can have a administrative interface to T24 such that creating an external user will also result in a
user id been created within 4TRESS. This via a java interface

 It has scope for additional memorable data

 4TRESS has a web based administration interface

 It requires a standard database such as Oracle

 4TRESS also supports VASCO tokens

RSA Features:

 RSA though supported by Temenos has notably fewer features than 4TRESS

 RSA Authentication Manager supports tokens only or very basic password only. It does not support
the use of memorable

data

 It does not have an administrative interface to T24. New users have to manually add to the
authentication server

Ncipher:

 NCipher is one of the HSM vendors supported by 4TRESS. NetHSM avoids need for three devices.
4TRESS can use NCipher HSM to compare partial memorable data within HSM

All three can provide global pre-sales support direct to prospect. We do not resell, but may receive a
finder’s fee.
You will find pictures of tokens from ActivIdentity above. They may simple tokens as the one found on
your right or more complex ones with a keypad which allows users to key in a seed based on which the
OTP may be generated.
Various types of RSA tokens are shown here. They may be simple, card based, USB pluggable or even
part of your Blackberry.

a. T24 Operator creates an External User account

b. This triggers new T24 code that invokes a 4TRESS management component via CALLJ

c. This component generates a T24 password and 4TRESS user id

d. These credentials are encrypted using the HSM

e. 4Tress user id and T24 credentials are stored in the authentication server
a. You login using the 4TRESS user id, a PIN and a one-time password generated by a device

b. The authentication code checks if you have logged in already and if not passes your credentials to an
authentication server

c. Successful authentication results in a valid security context in the web session, as well as returning
encrypted T24 login details that are stored against that user in 4TRESS. Note that the end user does not
know their T24 credentials

e. The authentication code then decrypts the T24 login details by using a hardware security module

f. It then submits a login post request to Browser, which logs in as normal. This is known as
“impersonation”
T24 serves both internal and external clients. The authentication flow is as follows:

 User requests page from web application

 Log in page displayed. User enters credentials

 Credentials sent to web server as a form post over HTTP

 App server calls our login module

 Login module authenticates credentials (e.g. token, PIN)

 Authentication server returns T24 username and password

 Login modules creates ‘login’ XML

 XML sent to T24 (via TCC / TCS)

 XML response sent to servlet

 XML transformed to HTML

 HTML returned to client

User Id: Arbitrary number (suggest 9 digits)

Name: Friendly name for greeting

Password review: the password review period. Current browser gives a user control for selecting the
review period.

 
Channel type: INTERNET (most important)

Status: Make sure it is ACTIVE

Arrangement: The arrangement id. Arrangement ids usually start with AA. Common mistake is to copy
the Arrangement Activity id

Start / End date: Start and end date for the user

Attempts: This has no significance in a real time 2 FA scenario, since the user id and password are picked
from the Authentication server and therefore there should be a valid. Hence the user will be able to
login the first time that he or she gets past the authentication server.

We enforce security at various other points when a user accesses over the net:

a. Menu – the first level of access control is through the use of menus

b. Servlet filter – the servlet filter allows us to restrict access to certain versions and enquiries
c. Enquiry selection – we add the condition CUSTOMER EQ! EXT.CUSTOMER to all enquiries to ensure
that users sees their own customer records only

d. And last (but not least) the USER.SMS.GROUP is used to control access rights to applications and
versions

Some of the recommended security practices are: 

 Setting up of Multi-level firewalls

 Setting up a Reverse Proxy server

 Ensure that the Generic user has access restricted access to applications

 Use the IBServlet filter to restrict to specified Versions and Enquiries

 Use a Primary authentication system third-party validated supplier

 Use a HSM for encryption key storage

 Have minimum code in Servlet Container/Web Server

Determines whether obfuscation of T24 commands should

be used or not.

-->

<parameter>

<parameterName>useInternalObfuscation</parameterName>

<parameterValue>NO</parameterValue>
</parameter>

<!--

Determines whether obfuscation and compression of

JavaScript should be used or not.

-->

<parameter>

<parameterName>useExternalObfuscation</parameterName>

<parameterValue>NO</parameterValue>

</parameter>
ARC-IB offers intermediary support through the Proxy Services product line.

The Internet Services product line would also have a specific product created for intermediaries, since
the rights and privileges and therefore the pages seen by a user who acts as an intermediary would
differ from ordinary users.

Product AP must be enabled in Company to use Intermediaries.

Let’s try to understand intermediaries with an example.

Mr. Branson signs an agreement (an arrangement in ARC-IB terms) appointing Mr. Wilson as his proxy.
This is what is known in ARC-IB parlance as a “Proxy Services Arrangement”.

Mr. Wilson requests the bank to provide access to Mr. Branson’s accounts. He provides the agreement
authorising him to act on Mr. Branson’s behalf. The bank grants access to Mr. Branson’s accounts. This is
an “Internet Services Arrangement”.
R Branson (Customer id 100297) wishes to use Wilson (Customer id 100411) as his intermediary. How do
we do this in ARC-IB?

Create a Proxy Services arrangement for R Branson. This arrangement would spell out the portfolios and
accounts that Branson wishes Wilson to have access.

Create an Internet Services Arrangement for Wilson. A special intermediary product may be used
instead of the usual product. The Allowed Customer field in this arrangement would contain Branson’s
customer id and the proxy services arrangement would contain the id of the arrangement created for
Branson.

Finally, create an EB.EXTERNAL.USER for Wilson.

Note:

Branson may have a normal internet services arrangement and EB.EXTERNAL.USER in case he needs to
access his accounts / portfolios through the internet.
You can see the proxy services product line with its corresponding product group and product in this
screenshot. It is a product line, which means this must be having a different combination of property
classes, right? Shall we see what they are?
What are the classes under the Intermediary Product Group? There are two Property Classes, namely
CUSTOMER and PROXY.PERMISSIONS.

This screenshot shows the MB.INTERMEDIARY product used by the intermediary.

As you can see, this is yet another product under the INTERNET.SERVICES product group. This product is
used to create an intermediary user profile.

Is there anything different about this product when you compare it with the Personal products? Move
on and see.
Take a look at the Intermediary Profile.

You can see the Personal net banking user profile in the second screenshot.

The Properties used in both profiles are more or less the same.

The differences are primarily in the Product Conditions for User Rights and UI Behaviour.
What are the differences in these two product conditions?

1. The product condition for the User Rights specifies a different SMS Group from that used for the
Personal profile. For example, the sample Model Bank intermediary profile uses a SMS group named
AP.INTERMED whereas the personal profile uses a SMS group named AI.PERSONAL

2. Secondly, the UI Behaviour property specifies a different Login page. The functionality and therefore
the page seen by an intermediary must be different from that of the normal user. For example, the
sample model bank intermediary profile uses a page called AP.MAIN whereas the personal profile uses a
page called MB.AI.MAIN.PERSONAL

Now that you have seen the differences, let us create an Intermediary or Proxy Services arrangement.
Well, let us go and create a Proxy Services Arrangement now.

1. Select Product Catalog from MB User menu

2. Choose the Proxy Permission product from the Proxy Services product group

Note:

Names used for product groups and products may differ in different releases of Model Bank.
This shows a proxy arrangement been created for Customer 100297. As you can see the values under
the Customer property tabs are self explanatory.

1. Let us look at the Intermediary tab

2. Customer 100411 acts as the proxy (for Customer 100297)

3. This proxy would have access to the account information pertaining to portfolio 100297-1 and
100297-2 of customer Branson

Similarly customer 100404 could also ask Wilson to be their intermediary. This means that customer
100404 would need to create a Proxy Services arrangement also.
You now need to create an Internet Services arrangement. These are the steps:

1. Choose the Intermediary Product from the Internet service product group. Create a new
arrangement

2. The sample here shows an arrangement created for customer 100411. This was the customer that
was named as the proxy previously

3. Under the User Rights tab, enter the arrangement id of the proxy services arrangement and the
customer id of the customer (for whom you will act as the proxy), in the proxy arrangement and allowed
customer fields respectively. The screenshot shows allowed customers as 100297 and 100404 along
with the id’s of the proxy services arrangements created earlier
Finally, create an external user using the internet services arrangement. You can see a sample
EB.EXTERNAL.USER record in the screenshot. Now you should be able to login to T24 through ARC-IB.

This is the page that appears when you login as your proxy user. Notice that the customer list shown
here corresponds to the allowed customers that you specified in the user rights properties.
How does all this happen? Well, Proxy Services doesn’t do anything magical. It sets a group of External
variables. Some of them are listed above.

These session variables are used in SMS, Versions and Enquiries.

The user page that you see when you login is a composite page AP.MAIN containing a menu
AP.MAINMENU. This calls a submenu called AP.SUBMENU.

The submenu calls three queries:

1. AI.WELCOME

2. AP.CUSTOMER.LIST

3. AP.PORTFOLIO.LIST
Observe the fixed selection criteria and the use of the external variable to restrict access to CUSTOMERs.

Observe the fixed selection criteria and the use of the external variable to restrict access to PORTFOLIOs.
The USER.SMS.GROUP grants access to selective group of queries and applications.

Now you try to create an Internet Services Intermediary product called Agents. Agents should be able to
see Customers, Portfolios and Accounts of those on whose behalf they act. (Create whatever Properties
and Product conditions that you deem necessary to do so).
 

Create an arrangement for the Proxy Permission product. Also, create an arrangement for the Agents
product.

Create an EB.EXTERNAL.USER, login and test your product and arrangement.

Let us try to understand the differences between a Corporate Customer and an Individual (or Personal)
Customer with an example. Now remember a personal customer will have a customer id, posses one or
more accounts and would posses a net banking logon id that would enable him to access those accounts
over the internet.
 

Let us take a company called ABC Industries. This has a customer id for eg 11307 and possesses a
number of accounts. Who would need to access these accounts? Not a single person but various
personnel of ABC Industries such as the CFO, Directors, Finance Manager and Accounts Executives. ARC
IB provides for this kind of access.

Now whether they get access to all the accounts of the company, and what they can do with those
accounts, would be different based on their role within the organisation. For e.g. the CFO may need to
look at not only ABC industries accounts but that of any other subsidiary or group company. The
Director on the other hand may need to look at ABC Industries’ accounts alone. An Administrator on the
other hand does not need to look at the accounts themselves, but may require special privileges to
control access to those accounts.

These personnel also would be ‘customers’ of the bank – but, they need not hold an account with the
bank. The CFO could hold a customer id say 11315 whilst the Director may hold a customer id 11321.

ARC-IB offers corporate support through the Proxy Services product line. And yes, you are right it is very
much similar to Intermediaries.

 
The Internet Services product line would also have specific products created for different corporate
users, since the rights and privileges and therefore the pages seen by different corporate users could be
different from one another.

Product AP must be enabled in Company.

Let’s try to understand corporate banking with an example.

ABC Industries signs an agreement (an arrangement in ARC-IB terms) appointing their Clerk1 as a proxy.
This is what is known in ARC-IB parlance as a “Proxy Services Arrangement”.

Clerk1 requests the bank to provide access to ABC Industries accounts. He provides the agreement
authorising him to act on ABC Industries behalf. The bank grants access to ABC Industries accounts. This
is an “Internet Services Arrangement”.
Clerk1 (Customer id 111319) is the corporate user for ABC Industries (Customer id 111307). How do we
do this in ARC-IB?

Create a Proxy Services arrangement for ABC Industries. This arrangement would spell out the portfolios
and accounts that ABC Industries wishes Clerk1 to have access.

Create an Internet Services Arrangement for Clerk1. A special corporate product may be used instead of
the usual product. The Allowed Customer field in this arrangement would contain ABC Industries
customer id and the proxy services arrangement would contain the id of the arrangement created for
ABC Industries.

Finally, create an EB.EXTERNAL.USER for Clerk1.

If you are thinking, isn’t this what I did while setting up an intermediary, yes, you are right.

However, in the case of an intermediary, we normally think of an intermediary acting on behalf of one or
more customer. This is sort of in reverse, where we may have one or more corporate users acting on
behalf of a corporate customer.

A corporate user may also have more than one allowed customer field. Why do we need this? For
instance, a corporate user who happens to be the CFO of a company may need access to the various
company accounts. However, a Proxy Arrangement is needed for each company that the CFO has access
to.
A corporate net banking customer may have different categories of users. Each user then has to be
created using different products. Each product may have different values, i.e. - product conditions
assigned.
You can see three different products for Corporate Banking shown here. They are CORPADMIN,
CORPAUTH and CORPINPUT.

These have been created on the broad assumption that a corporate customer would require users who
will input transaction other who would authorise transactions and lastly users who would not have
anything to do with financial transactions but would perform administrative tasks such as managing
users.

You can see the Property conditions of the three products shown here. These differ in terms of the User
Rights and UI Behaviour property conditions.
Let us take a look at the Product Conditions listed earlier.

Shown here is the product condition of UI Behaviour named CORPADMIN:

 Notice the Flow Value fields

 These are different for the product condition CORPAUTH

Shown here is the product condition of User Rights named CORPADMIN:

 Notice the SMS Group field

 These are different for the product condition CORPAUTH

Let us look at the SMS group profiles that have been used.

SMS is implemented using various session variables shown above. Let take a look at a typical
USER.SMS.GROUP for the corporate user next.
You can see the USER.SMS.GROUP record AI.CORPAUTH which is used to specify access rights for those
who can authorise transactions. Notice that the session variables EXT.SMS.CUSTOMER and
EXT.SMS.ACCOUNTS have been used to control access to the Account and Stop Payment applications.
You can see the USER.SMS.GROUP record AI.CORPADMIN which is used to control access rights for the
Administrators. Notice that the session variable EXT.SMS.CUSTOMERS has been used to restrict access
to specific records in AI.CORPORATE.USER.

Session variables are used in enquiries to limit access to records pertaining to that corporate user. This
page shows the enquiry.
 A list of menu items need to be displayed for a corporate user are controlled through a table
called AI.CORPORATE.USER. This table is defined in EB.TABLE.DEFINITION.

A nofile enquiry called AI.CORP.GENERAL or MB.AI.CORP.GENERAL queries this table and produces a drill
down enquiry output.

The account details are displayed using an enquiry called AI.CORP.AC.ACTIONS (or
MB.AI.CORP.AC.ACTIONS).

The menu for administrators is a standard menu called AI.CORP.ADMIN.MENU.

You need to:

 Create a proxy services arrangement for the corporate customer

 Create an internet services arrangement using the corporate profiles you saw earlier for another
customer (do not use your corporate customer). Enter the customer and arrangement id used in step 1
as the allowed customer and proxy arrangement

 Create an eb external user

ARC-IB supports the notion of mandates for corporate banking users. We will see how to setup and use
mandates.

T24 supports the notion of zero, one and two authorisers for a transaction.
All parties, inputters as well as authorisers, must have different logins.

When two authorisers are required, it can be set to be either any two with authorisation rights or a level
one authoriser and a level two authoriser.

Mandates are linked to individual accounts.

This allows transactions to be authorised subject to a number of signatories, signatory levels and
transaction value.

The signatory has to be entered into a transaction. This is done manually in the case of internal users
and automatically for internet users.
What does the above table signify?

There are four groups of signatories:

1. To authorise 1000, you require two signatories from Group A

2. To authorise up to 5000, you require one signatory from Group A and another from Group B

3. To authorise up to 20000, you need two signatories from Group B

4. To authorise any amount beyond 20000, a signatory from Group C and another from Group D
Three new applications have been included in T24 to support mandates. They are:

EB.SIGNATORY.GROUP - this groups signatories together

EB.MANDATE - this application is used to specify the actual mandate details such as who are the
signatories (or at least signatory groups), the number of signatories from each group and transaction
limits

EB.MANDATE.PARAMETER table - this is used as a lookup of each application to indicate the amount
field
Modification has been made to CUSTOMER, ACCOUNT and PORTFOLIO to accommodate mandates.
When a transaction is input, T24 checks for mandates against the particular account, then the portfolio,
failing which the customer.

Fields Mandate Application, Mandate Record and Mandate Reg have been added to Customer, Account
and portfolio.
Applications that allow mandates are:

 Funds Transfer

 Standing Orders

 Bulk Standing Orders

 Direct Debits
Look at the sample EB.SIGNATORY.GROUP shown here. This defines a signatory group called
1000009.DIRECTORS.The first part of the id is customer id of the corporate customer, whilst the second
part is a user defined name.

The signatory group contains the id’s of valid signatories. These are typically id’s of corporate users. The
start and end dates, define the validity period of a particular signatory.
EB.MANDATE is used to specify the actual mandate details. The id of the record composes of the
Corporate Customer’s id followed by the effective date followed by a sequence number.

The Up To Amount field specifies the transaction limit. The signatories are specified in Signatory Group.
This could be the id of a record in EB.SIGNATORY.GROUP or a Customer id. Customer id’s are directly
used for corporate users who do not fall under a signatory group. E.g. Chief Executive.

What happens if the transaction is in a different currency say GBP? It is converted to the Limit Currency
specified in mandate and compared against the Up To Amount.

Min No Signatory spells out the minimum number of signatories from a particular signatory group. The
above screen shot specifies that transactions up to 100 USD must be authorised by one DIRECTOR and
one CLERK. Amounts up to USD 50,000 must be sanctioned by two DIRECTORS.

Note:

The Up to Amount field if left blank signifies that the signatories apply for an infinite amount. While
specifying multiple amounts take care that they are given in an ascending order.
EB.MANDATE.PARAMETER specifies the lookup table of each application. This is used to determine
which amount field, currency and date should be picked from the application and checked against the
mandate.

For instance the above screenshot shows EB.MANDATE.PARAMETER entry for FUNDS.TRANSFER. The
Amount field is given as CREDIT.AMOUNT which means that the CREDIT.AMOUNT (and not the
DEBIT.AMOUNT) will be checked against the mandate up to amounts.

The currency to be considered for this amount is given as the CREDIT.CURRENCY. Finally, the
CREDIT.VALUE.DATE is checked to see if it falls within the start and end dates given in the mandate.
Well, now that we have seen how to set up a mandate, we next need to enable that mandate for a
particular customer (or account or portfolio). The screen shot shows the mandate applied to customer
1000009 (who if you recall is our corporate customer).

The field Mandate Appl.1 contains FUNDS.TRANSFER indicating that this particular mandate applies to
funds transfers, and the mandate record to check has an id 1000009.20090107.1

If a mandate is enabled on a customer it applies to all accounts for that customer except those that have
their own mandates. However, if the mandate is enabled on an account it just applies to that account.
Let us try to use this mandate. Suppose you try to effect a Funds Transfer from an account belonging to
the Customer having a mandate. What happens? You get an override message which says “Minimum
Signatory not reached”.
Here you can see another Funds Transfer. However this Ft contains a signatory (the id of one of the
customers specified in EB.SIGNATORY.GROUP). Therefore this does not raise an override.

How does mandate function in ARC-IB? the fundamental idea is the same. i.e the signatory field in the
mandate compliant application, in our case Funds Transfer, must be populated. In ARC-IB this is done by
using the Ext variable EXT.EXTERNAL.USER to populate the signatory field.
Now, you try to create an EB.SIGNATORY.GROUP for corporate customer 100226 called CLERK. The
signatories are customers 100021 & 100022.

Create a mandate for customer 100226 such one clerk’s signature is required for transactions up to 5000
USD.

Add the mandate to the customer.

Create a proxy permission group for customer 100226 grating proxy rights to one of the clerks say
customer 100021. Make sure to add at least two accounts, one of which should contain sufficient
balance.

Create a Corporate Inputter user for this clerk, i.e. customer 100021. Put through a funds transfer in
ARCIB.

Create one more proxy for the same corporate customer and see what happens when you put through a
Funds Transfer.
Now, you try to create a mandate as discussed here.

For amounts up to 1000 USD requires two signatories both of whom must be clerks.

Alternatively, it could be signed by a director.

Amounts up to 100000 require two signatories both of whom must be directors.

Amount more than 100000 requires the CFOs authorisation.

Only support FT, STO,BULK STO and DD (Direct Debit)