Introduction to Teller
The TELLER module in Temenos Transact processes a variety of retail transactions. It is an account based application for moving funds. It incorporates the administration of tills, processing of local and foreign currency transactions, travelers’ cheques, currency transfers, denomination control, passbook updates, advice production, automatic charges defaulting, and rate defaulting.
The variety of transactions can be configured easily in Temenos Transact by the menu system or by using role based home pages and can be customised for each user or bank. Also, various risk mitigation functions such as teller limits, maker checker concept, stock control and so on are also incorporated for better transaction and operation control.
Configuring Teller
Although the system processes many types of transactions, the basic mechanism for balancing entries, defaulting rates and charges remains the same. Hence all transactions are processed by the one application (TELLER), but the screen prompts can be varied by tailored VERSION with specific defaults being controlled by a TELLER.TRANSACTION.
Each transaction prepares two balancing accounting entries (more when charges are present). Invariably, one side is the client (side 1) and the balancing entry is the teller cash account (side 2), that is, a simple cash deposit entails a credit to the customer account and a debit to the teller cash account.
In the Teller system, the cash that is held at a teller's position is recorded in an internal account defined as:
<CURRENCY-CASH CATEGORY- TELLER ID>
For Example : USD-10000-0012

The Cash Category is specified in the TELLER.PARAMETER file. It is the balance of these account records, it can be reconciled with the actual cash when the till is closed.

Cheques have to be posted directly to the collection accounts and not held by the teller (defined in TELLER.TRANSACTION). This allows for easy reconciliation of funds as each cheque is recorded as a separate entry to this account.

It is possible to specify an exposure date on the teller contract, which is used to decide when the funds credited gets updated to the cleared balance on the account record. It is also possible to clear funds on a single teller transaction on multiple dates. This information is entered in the exposure date ladder fields (Exp Split Date and Exp Split Amt). Although the splitting information can be entered manually, they may also be made to default using either the TRANSACTION record or the BC.SORT.CODE record. Read Local Clearing and System Table for further information on setting up exposure date splitting defaults.
It is also possible to default the value date on the credit side by specifying a sort code that points to a BC.SORT.CODE record set up with a default value date period.

The Till Limits functionality helps currency wise till level limits to be maintained in each till based on the setup in TELLER.ID. The limits, whenever breached by a teller transaction, raises necessary overrides. Also, overrides are raised (whenever a till is opened or closed) when limit definitions are not made for currencies found in the stock, but the limit field is set in TELLER.ID.

Charges for customers’ account to account transfer transaction can be collected from any account. This allows flexibility to collect charges either from the remitter, beneficiary or a third party account.
Chg Type field in TELLER.TRANSACTION and TELLER applications and Charge Account field at TELLER level allow the user to specify the charge account .The charge account can be in any currency.

- It is possible to capture the card number attached to the debit account in the transaction.
- The card number has to be entered in the Card Number field at the time of transaction.
- There are validations are to check that the card number input has been issued to the debit account number.
- If a different card number is entered, the system gives an override message.
- If the card number does not exist, the system gives an error message.
- It is also possible to capture the details of the card transaction in a text field.

The following two functions are performed at the COB for TT.END.OF.DAY Teller transactions.
- Remove any unauthorized transactions and place on hold.
- Transfer all authorized transactions to history. This means that under normal circumstances, the transaction file is empty at the start of each day.
- If passbook processing is active, then the TELLER.PASSBOOK.STMT COB process updates the ACCOUNT.STATEMENT and the associated files with the details of passbooks updated on that day (see TELLER.PBOOK.PRINTED).
- This process emulates the updates that take place if a statement had been produced.
- A passbook update is viewed as a statement by the system.

Profit and Loss (P and L) entries in Foreign Currency (FCY) can be entered in TELLER. The functionality is similar to the FUNDS.TRANSFER application. The other leg of the teller transaction must also be of the same FCY, otherwise the system produces the error message as shown in the image below.

Advices can be printed from any teller transaction. The format and content is user definable through the DEAL.SLIP.FORMAT application.
To define an advice, the details have to be entered into the DEAL.SLIP.FORMAT application. This file describes the data that has to be extracted from the deal and where, on an advice, it has to be printed. It also allows free format text, totaling and data to be extracted from associated files.
This advice can now be linked to an individual transaction, by entering the DEAL.SLIP.FORMAT key into the Advice Version field of the TELLER.TRANSACTION record. If the advice has to be printed by default, then the Print Advice field in the TELLER.TRANSACTION record has to be set to Y. An override can be requested if the teller does not produce the advice. The below image shows how a specific DEAL.SLIP.FORMAT record is assigned to TELLER. TRANSACTION
The advice is printed whenever the Prt Hotkey is depressed (defined on the TERMINAL record) or if the DEAL SLIP button is clicked when using the browser. The advice can be printed at any stage during the transaction, which means that the customer prior to committing the transaction can sign the advice.
Illustrating Model Parameters
The following are the model parameters related to Teller.

It defines the category and transaction codes to be used for balancing tills, Tran category to be used for cash, rounding details for local currency and the vault ID.

This defines the defaults and validation to be used for teller transactions. It also defines the accounts for both sides of the transaction, the charges (if any), the transaction codes, Curr Mkt and duplicate check to check for the occurrence of any duplicate contracts.

This parameter defines the description and value of the denominations in use for each currency. It also defines the units, coins and notes in use for each currency. A prerequisite to setting up this parameter, is to set up the appropriate DENOM.TYPE like Cash, Travellers Cheque, and so on.

This parameter allows the user to define the format of the data output on a savings account passbook. The SYSTEM record is the only one allowed in this parameter.

This parameter for authorisation is used to pick up the appropriate versions while amending or deleting or authorising the teller transactions through the menu and home Pages. If the input version is not specified in this parameter file, then while amending, authorising or deleting the teller transaction, the TELLER application is launched instead of the version that is used to input the transaction.

This parameter is used to define the various denomination types like Cash, Gift vouchers, Travellers cheque, and so on that can be attached to the TELLER.DENOMINATION, so that denominations in teller transaction can be filtered based on the denom types.

The Teller Financial Services (TFS) applications allow the user to enter multiple financial transactions on the same screen and commit all of them as one transaction. This application is the main transaction at front end. It captures the user input data and creates a TELLER or FT or a DC batch in the backend.
Illustrating Model Products
Model Products are not applicable for this module.
In this topic