T3TRP - Repo - R14 1

This course enables us to know about the Repo module, its linkages with core
tables, setting up of parameters, inputting different types of Repos, viewing the
accounting, delivery and enquiries and reports.

T3TRP - Repo - R14 2

 “Repo” means a “repurchase agreement” that involves sale of security for
consideration (money) with an agreement to reverse the deal at a later date,
counterparties understand that the transfer of security (in one direction) and the
transfer of money (in the other) is temporary, transaction is equivalent to a
loan of securities in one direction and a loan of cash in the other, so that the
economic benefit of owning the securities, income and capital gains/losses,
remains with their original owner, driven either by the need to lend cash,
which is collateralised by securities, or the need to borrow specific securities.
Legal title i.e. ownership of the collateral passes to the buyer for the life of the
REPO . Although the buyer is entitled to the coupon as legal owner, they are
only holding the security as collateral, their financial gain comes from the
interest on the cash loan. Coupon is therefore passed back to the seller. In a
REPO contract, the original owner retains the benefits and risk of ownership,
though legal title has passed to the counter party. T24 REPO module supports
the recording, processing and administration of both REPO and RESO
transactions. It incorporates these transactions into the Limit, Accounting and
Position Management modules within T24 and supports a wide variety of
REPO and RESO types, such as: Bond REPO , Gilt REPO , Equity REPO
,Bilateral REPO, Trilateral REPO ,Cross currency REPO, Open REPOs ,
Buy/Sell Back, Sell/Buy Back, Stock Borrow / Lending.
BSB and SBB are not restricted to trading via a legal agreement like REPOS

T3TRP - Repo - R14 3

 therefore a lot of banks use this instrument as it allows the banks to sell and buy back
the stock at an agreed amount and date. No margin call are possible on these repo
types as in affect we are linking two security transfer together

T3TRP - Repo - R14 3

 All modules in T24 will require CUSTOMER & ACCOUNT module to begin
any activity. We need to have Customer records to refer the counter party in a
RESO Contract and Investor in a REPO contract. Brokers & Depositories must
also be a valid Customer id.
CUSTOMER.SECURITY files needs to be created for Customer records for
them to use the securities module.
We need to specify accounts for draw down accounts and liquidation purposes.
Other related core modules required are Delivery, Accounting, Limits. The
delivery messages are generated after the transactions are authorised. The
accounting entries are passed and the credit / debit risks are checked via Limits
module.
All other core static tables are also required.

T3TRP - Repo - R14 4

 Category codes used for the REPO module is 21200 – 21999
Borrow – Stock Borrowing , BSB – Buy Sell Back
SBB – Sell Buy Back , INTBORROW – Internal Borrow
OPEN REPO – Open Repos, OPEN RESO – Open Reso's
REPO – Standard Repo, RESO – Reverse Repo

T3TRP - Repo - R14 5

 Different interest day basis for calculation of interest is possible, depending on
the methods followed for calculating number of days and days in a year.
If basis "S" is used then the system will require an entry in REPO.INTEREST
Field. Amount entered will be compared with the likely interest arising out of
the interest rate entered. Maximum tolerance allowed is 5%. An override will
be generated where the variance is greater than 1%; and a variance greater
than 5% will be rejected. The special (S) Interest calculation method is only
allowed for fixed interest rate contracts.

T3TRP - Repo - R14 6

 PERIODIC.INTEREST table is used for “LIBOR” type rates . Rates vary
depending on the length of time and for Bid and Offer purposes.
At the scheduled dates the system will refer to this table and automatically
“picks up” the relevant rate and apply that to the contract until the next review
date.
This table maybe automatically updated/interfaced daily with an external feed
such Reuters, or maintained manually by the user.
PERIODIC.INTEREST keys are generated by the System on daily basis. It is
possible to effect changes in rates of dates prior to system date.
As a result, all MM contracts which had accessed the (changed) key at an
earlier date, will recalculate interest based on the changed interest rates.
It is possible to stipulate the extent of interest tolerance to be allowed for MM
contracts in the INT.TOLERANCE Field. A tolerance entered here will be
used to check if an over-ride is required for any interest rate difference.

T3TRP - Repo - R14 7

 Holiday table will be used to check whether maturity or other scheduled
activity date falls on a working day or not at the time of inputting a REPO
contract. Accordingly, at the time of contract input, holidays for those
countries and regions will be checked for all scheduled activities and suitable
overrides will be generated. Interest day basis will be defaulted to transaction
records as per the currency used. It is possible to change the interest day basis
at the record level or contract level.
CURRENCY.PARAM table contains common details for each Currency to
ensure that the same numeric code and no of decimals are used on different
currency files in a multi company environment.
It is possible to create different market rates for the same currency namely
separate rates for Notes or Travellers Cheques etc. Up to 99 markets can be
indicated in CURRENCY.MARKET table. Consolidation keys are formed
market wise. Markets beyond 9 will be consolidated with the market type of
the first digit for example 10 with 1.

T3TRP - Repo - R14 8

 The accounts attached to a portfolio is used to identify the account over which
the accounting entries for this portfolios transactions are to be passed. The
rules for defaulting of account numbers for a specific transaction could be set
up. If a settlement account is not available for specific transaction, then system
defaults first account in the trade currency mentioned. If account in trade
currency not available then first account of the portfolio gets defaulted. If only
a GBP account is entered and customer deals in USD securities, the system
defaults the GBP account and use the standard exchange conversion rates to
convert amount from USD to GBP. However if a GBP account and USD
account are available then, for a transaction dealing in USD securities default
will be the USD account. If more than 1 account specified for a currency, say 2
GBP accounts, then the first GBP account will be defaulted for a transaction of
GBP securities. At least one account needs to be linked to the portfolio.
Account must belong to the customer of the portfolio and cannot be linked to
another portfolio.
The default settlement instructions for a broker could be set up through
CUSTOMER.SECURITY. The broker settlement account is generally the
Nostro over which the financial entries are to be posted. Payment can, if
required, be effected over a Vostro ACCOUNT also. To affect a default, you
will have to ensure that there is a record existing for the settlement currency on
the NOSTRO.ACCOUNT file specified for use by the SC application.

T3TRP - Repo - R14 9

T3TRP - Repo - R14 10
 T24 REPO module supports recording, processing and administration of both
REPO and RESO transactions.
To perform the above said activities it is required to have certain parameter
files set up, which includes files from Securities module and also from Money
market module to make the REPO settings complete.
The parameter tables to be set up during implementation are
REPO.PARAMETER, REPO.TYPE, REPO.AGREEMENT.TYPE,
NETTING.AGREEMENT, RP.GROUP.PARAMETER. Additionally security
module related tables like CUSTOMER.SECURITY, SEC.ACC.MASTER and
SECURITY.MASTER and the table related to MM module have to be used.
It incorporates these transactions into the Limit, Accounting and Position
Management modules within T24.

T3TRP - Repo - R14 11

 REPO.PARAMETER is the top-level parameter file. The key is the Id of the
company to which the parameter record refers.
It holds the definitions of:
- valid portfolio suffixes for the counterparty margin portfolio
- booking method of the initial margin
- limit update treatment for REPO contracts
- no. of days post maturity that contracts are moved to history
-The suffixes mentioned in this file is to be used for creation of margin
portfolio keys during a REPO, RESO, Stock lending, Stock Borrow, Customer
Repo contracts. These entries will be used in REPO.TYPE for further
configuration.
The initial margin of a REPO contract can be used as a device to undervalue
the securities involved; hence to cover the risk of the adverse movement of the
securities, which may arise before a margin call, can be made.
INIT.MRGN.BOOKING Field is used for this purpose.

T3TRP - Repo - R14 12

 A REPO contract is treated as a loan of securities and a deposit of cash.
However, the bank may see the loan of the securities as a potential risk, and
may wish a REPO contract to update the T24 limit processing as if it were a
loan – thus decreasing the available limit. This definition of whether the limit
for a REPO contract is regarded as either a LOAN or DEPOSIT is defined in
this REPO.LIMIT.UPDATE Field. The number of days after maturity that a
matured contract remains on the live file is also specified in
DAYS.POST.MATURITY Field.

T3TRP - Repo - R14 13

 AUTO.CALC.NOMINAL Field works in conjunction with the
CALCULATION.LINK Field. If this Field is set to “YES” and the
CALCULATION.LINK Field inside the REPO contract is also set to “YES”
then when a cash driven REPO contract is entered the system will
automatically calculate how much nominal is required of a particular security
to meet or exceed the principal amount.
With UPDATES.SC.POS.SOD Field it is possible to have the
REPO contract generate the near leg SECURITY.TRANSFER
record immediately on authorization of the contract regardless of
the value date. This can be achieved by setting the Field
UPDATE.SC.POS.SOD to ‘YES’. This is a no change Field.
Additionally, setting this Field to ‘YES’ triggers the updating of the
SECURITY.POSITION on account of the far leg of the
SECURITY.TRANSFER at SOD

T3TRP - Repo - R14 14

 Using PROCESS.REPO.SOD Field, contracts can either be processed during
the Start of Day (SOD) or Close of Business (COB). This accepts the values of
“NULL”, “FWD TO LIVE”, “MATURITY” or “BOTH”. If set to “NULL”,
transactions turn live / mature at COB. Using this Field, it is possible to
selectively process contracts becoming live or maturing at SOD. If the Field
UPDATE.SC.POS.SOD is set to ‘YES’, then this Field will accept only values
of ‘MATURITY’ or ‘BOTH’.
ENT.CPN.SUSP Field is used for Corporate Actions, where it allows changing
the ACCOUNT.NO Field in the ENTITLEMENT record for the RESO
positions. If this Field is updated then the RESO entries will be posted to this
specific account.
SPLIT.DEBIT.CPN Field when set to ‘YES’, the cash entries relating to REPO
contracts are posted to this Nostro account. This process is possible if the
ACCOUNT Field is updated for the REPO application in the
NOSTRO.ACCOUNT record. The NOSTRO.ACCOUNT record must be
keyed on the security currency of the DIARY.
The REPO application automatically creates AC.BLOCK.CLOSURE records
when the Field NEW.CU.ACCT.NO is populated. These records are then
interrogated when the application ACCOUNT.CLOSURE is used to prevent
closure if a live REPO contract is using the account. So caution should be used
when setting it to NO as internal processes must exist to prevent such

T3TRP - Repo - R14 15

 occurrences.

T3TRP - Repo - R14 15

 This application holds records, which control how each type of REPO contract
entered will be processed. Each REPO contract must have a valid
REPO.TYPE entered.
Configure REPO.TYPE as a “LOAN” (REPO) or a “DEPOSIT” (Reverse
REPO).
Product category to use (CATEGORY file).
Suffix for margin portfolios.
Definition of Customer REPO.
Category of suspense accounts for Customer REPO’s (CATEGORY file).
Transaction type used for Customer REPO’s (SC.TRANS.TYPE file).

T3TRP - Repo - R14 16

 CLASSIC : To be used for standard Repo or Reso trades.
OPEN : To be used for Open Repos. When the REPO.TYPE used in a
transaction has been set up as a OPEN Repo, the Maturity date on the Repo
transaction will accept a value of 0. Daily accrual of interest takes place on the
Principal Amt. Accrued interest is capitalised on a daily basis and is reflected
in the value of Field PRINCIPAL.AMT changing due to interest accruals.
BUY/SELL BACK : This type is used when the REPO trade is treated as a
purchase of the security, with an agreement to sell back the security at a
predetermined price. The sale price would comprise of the purchase price + the
Repo interest + any corporate action that may have been paid on the security.
SELL/BUY BACK : The opposite of a BUY/SELL BACK.
INTERNAL: An internal trade moving stock from a bank portfolio to a
customer portfolio.
STOCK.BORROW.LEND: To be used when using Stock Borrowing/Lending.
Delivery instructions – DAP Delivery against payment, FOP – Free of
Payment, FRE – Delivery with payment, NIL – No delivery, No payment, PAI
– Payment only
Valid basic repo types are CRR, OPENRESO, RESO on the Loan side and
CREP, OPENREPO, REPO on the Deposit side. DAP types BSB and SBB.

T3TRP - Repo - R14 17

 These types defined in REPO.TYPE file

T3TRP - Repo - R14 17

 Both legs of REPO contracts are often transacted under one agreement. The
PSA agreement is used in the US, whilst in Europe the PSA/ISMA General
Master REPO Agreement (GMRA) is the standard increasingly used.
REPO.AGREEMENT.TYPE table is used to define the various standard
agreements . If we define it avoid the need to define complex narrative in the
contract . In addition any further conditions can be specified on the contract.

T3TRP - Repo - R14 18

 RP.GROUP.PARAMETER application allows the user to specify the 'grouping'
criteria for REPO contracts that require delivery messages to be 'netted'.
The REPO application contains a Field indicating the 'netted/grouped' status of
the individual contract as determined by the criteria in this application .
ENT.NET.SUSP Field determines which suspense account will be used to
group the REPO transactions. A valid record in the CATEGORY application
is used.
The SYSTEM.FIELD is configured by Temenos & is the minimum number of
Fields that are required to match during the selection stage.
The USER.FIELD can be modified by the bank & will be additional Fields
from the REPO contract that will be required to match during the selection
stage.
The SELECTION.FIELD will be defaulted into the SC.GROUP.TRADES
application when a new application is to be considered for netting. The user
will be able to use these Fields to refine the selection criteria for matching
REPO contracts for delivery netting.
The ENT.NET.SUSP Field is used to determine which account the netting will
be posted over.
Payment messages are not netted.

T3TRP - Repo - R14 19

T3TRP - Repo - R14 20
 The order in which these files should be created is stored within the automated
implementation tool . For easy reference, the order sequence in the ascending
build reference order is given in the left.
The mandatory and optional files are shown by different colour codes.
Wherever there are dependencies for filling up values in the tables in build
sequence, the dependencies are shown on the right.

T3TRP - Repo - R14 21

T3TRP - Repo - R14 22
 T24 REPO module supports the recording, processing and administration of
both REPO and RESO transactions. It incorporates these transactions into the
Limit, Accounting and Position Management modules within T24 and supports
a wide variety of REPO and RESO types, such as:
Bond REPO , Gilt REPO , Equity REPO , Bilateral REPO ,
Trilateral REPO , Cross currency REPO ,
Open REPOs , Buy/Sell Back
Sell/Buy Back and Stock Borrow / Lending

T3TRP - Repo - R14 23

 We will now look into the business flow of a REPO contract.
On the value date, during initialisation of the deal, the investor receives
Security from the Repo dealer and gives Cash to the Repo dealer.
On the Maturity date, where there should be the reverse reaction, investor
receives the cash amount given earlier with interest and any margin calls made
during the tenure.
The repo dealer will receive either the same security, if there had been no
margin calls. But of it was subject to margin calls held on the security, then its
worth could be different.

T3TRP - Repo - R14 24

 Id of the record
Unique reference number which identifies a particular Repo contract
Format RPYYDDDNNNNN, where,
RP - Application indicator
YY - last 2 digits of the year
DDD - the Julian day number within the year
NNNNN - 5 digit sequence number
Repo type is used to define the characteristics of a REPO contract, and
reference a record on the REPO.TYPE file

T3TRP - Repo - R14 25

 TRADE.DATE is the date on which the contract agreed should be entered in
this Field. This Field defaults to the current business date.
VALUE.DATE records the date on which the trade is to be effected. The value
date for any transaction can vary from 1 day to 1 month depending on the
security being traded and the stock exchange at which it is being traded. It
cannot be less than Trade Date.
MATURITY.DATE is the date on which the Repo contract matures. Accepts an
input of 0 which signifies an Open Repo, i.e. one where the maturity date is
not yet known, which can be replaced with a maturity date at a later date.
On this date the securities will be returned to the seller and the buyer will
receive the buy back amount specified on this contract (as defined in the
PRINCIPAL.AMOUNT Field).
In the case of a REPO contract (i.e. the cash side is a deposit) the bank (as
seller) will receive the security from the bank, and the counterparty (as buyer)
will receive funds. The amount received by the counterparty is the amount
specified in the PRINCIPAL.AMOUNT Field of this contract.
Either a valid date must be entered as a date or a number of weeks or months,
i.e. 1W or 2M, in which case the date after the number of weeks or months
specified from the value date, taking into consideration the business centres
defined, will be created.

T3TRP - Repo - R14 26

 COUNTERPARTY Field holds the counterparty with whom the bank makes
the Repo contract. This information is used to determine the margin portfolio
to be used, where applicable, and the account numbers from this portfolio that
appear in the CU.ACCOUNT.NO Field. Mandatory input except for customer
repos where this Field will default from the CUST.PORTFOLIO. This is a
NOCHANGE Field. It must be the key to a valid entry on the CUSTOMER
file. It must exist on the CUSTOMER.SECURITY file.
BANK.PORTFOLIO Field can be used for Own Book and Customer repo
contracts.
The CUSTOMER REPO field in the REPO.TYPE should not be populated as
this field was created for a specific Bank’s requirements and is not to be used
for the market for customer Repo trading.
Where the REPO.TYPE is set as a CUSTOMER.REPO = Yes, this Field
should remain empty.
PRINCIPAL.AMOUNT.1 Field holds the price for the first leg of the repo
contract, specified in the currency defined in the CURRENCY Field. It is this
price that governs the movement of funds that will take place on the
VALUE.DATE of the contract.
PRINCIPAL.AMOUNT.2 Field holds the price for the second leg of the repo
contract, specified in the currency defined in the CURRENCY Field. It is this

T3TRP - Repo - R14 27

 price that governs the movement of funds that will take place on the
MATURITY.DATE of the contract.

T3TRP - Repo - R14 27

 REPO.RATE Field holds the rate of interest for the REPO contract.
Where entered, this rate is used to calculate the PRINCIPAL.AMOUNT.2,
which is the repayment amount to be made at maturity of the contract, using
the interest basis defined. Either this Field or PRINCIPAL.AMOUNT.2 must
be entered.
PRIN.INCREASE Field is used to make cash based margin calls. If a margin
call is to be made in cash, by increasing or decreasing the cash amount in
Principal.Amt.1, then an input would be made in this Field.
The date on which the margin call is to be effected is mentioned in the
MGN.CALL.EFF.DATE Field. During the Close of Business processing on the
MGN.CALL.EFF.DATE, the PRINCIPAL.AMT.1 Field is updated with the
new PRINCIPAL.AMT.1 (being the PRINCIPAL.AMT.1 + PRIN.INCREASE)
and the Field PROJECTED.CASH.AMT Field becomes null.
PRIN.INCREASE.INT Field is used where the special (S) interest basis is
used the system is unable to determine the amount of interest due for a
principal increase and this Field allows the user to specify the interest amount.
Unless the interest basis is S the user will not be able to amend this Field from
the value calculated by the system.

T3TRP - Repo - R14 28

 NEW.NOMINAL Field defines the nominal of the security that will become
part of the REPO contract once the contract is authorised. The securities that
will form a part of REPO or Reverse REPO contract, are defined in the Field.
CLEAN.PRICE Field stores the current clean market price for the Security.
It will automatically default from the LAST.PRICE Field stored in the
SECURITY.MASTER record when the NEW.SEC.CODE Field is populated.
It can be manually overwritten, in which case, the GROSS.AMOUNT &
DIRTY.PRICE Fields are recalculated.
DIRTY.PRICE Field stores the current dirty price for the Security which is
inclusive of any accrued coupon interest. It will automatically default when the
NEW.NOMINAL Field is populated using the following equation:
It can be manually overwritten, in which case, the GROSS.AMOUNT &
CLEAN.PRICE Fields are recalculated using the following calculations:
ACCRUED.INT.AMT Field stores the accrued coupon interest for the
Security & is calculated using information stored in the SECURITY.MASTER
record.

T3TRP - Repo - R14 29

 TOTAL.SETTLEMNT Field contains the total settlement amount for each
security within the contract. REPO.INTEREST Field stores the interest due on
the REPO contract using the REPO.RATE in the calculation.
FWD.SETTLEMNT is the total forward settlement amount for the far leg for
each security within the contract.
For BSB and SBB, it will be TOTAL.SETTLEMENT + REPO.INTEREST
+CPN.AMT +CPN.INVST.AMT Fields added up together to bring in
FWD.SETTLEMENT Field.
FWD.PRICE is the forward price for the far leg for each security within the
contract. It takes into account the accrued interest of the REPO Contract.
For BSB/SBB, this Field will be calculated as
((FWD.SETTLEMENT FWD.ACCR.INT) / NEW.NOMINAL) / FACTOR *
PERCENT. DAYS.DELIVERY Field specifies the number of working days, in
advance of the Process Date, that a message is to be sent by RP.DELIVERY.
If specified, its value will be used instead of the value specified in the
corresponding EB.ACTIVITY Field DAYS.PRIOR.EVENT.
REPO contract status – Trade date = Jan 1, value date = Jan 10, Maturity Date
= Jan 31 and DAYS.DELIVERY = 2, then
FWD – on Jan 1. INI – Jan 8 to 10.

T3TRP - Repo - R14 30

 CUR – Jan 10 to Jan 29 MAI – Jan 29 to Jan 31
MAT – on Jan 31

T3TRP - Repo - R14 30

 REPO.INTEREST Field stores the interest due on the REPO contract using the
REPO.RATE in the calculation.
Only fixed method allowed. It can be negative. The interest Days basis to be
set. If PRINCIPAL .AMT.2 given then system defaults REPO.RATE

T3TRP - Repo - R14 31

 If DEAL.TYPE used is ‘Classic’ REPO, The system creates two child
contracts. A SECURITY.TRANSFER contract to handle the transfer of
securities between the Bank or Customer (in the case of Customer Repos) and
the Counterparty. And a MM.MONEY.MARKET deal to handle the transfer to
money.
For a RESO, coupon payments received by the Bank have to be passed on to
the counterparty manually by using FT. The transaction maybe either cash or
security driven.

T3TRP - Repo - R14 32

T3TRP - Repo - R14 33
T3TRP - Repo - R14 34
T3TRP - Repo - R14 35
T3TRP - Repo - R14 36
T3TRP - Repo - R14 37
T3TRP - Repo - R14 38
T3TRP - Repo - R14 39
T3TRP - Repo - R14 40
T3TRP - Repo - R14 41
 For cash driven REPO transactions, on input of cash details, the security
nominal's are calculated, based on parameter settings
If multiple securities are used, then nominal's to be input by you.
When the security is input, price defaults from the Security Master file
If the security used is a bond, then clean or dirty price is used
Cash margin for the transaction to be furnished
For security driven transaction, cash amount is calculated. The Margin is
specified.

T3TRP - Repo - R14 42

 Input of cross-currency REPO is permitted, where the currency of the security
used in the REPO transaction differs from the currency of the REPO
transaction. The exchange rate to be used for such transactions is displayed in
the FX.RATE Field. The rate defaults from the currency table, however the
user has the option to change the rate defaulted by the system.
With the calculation link set to yes, once the foreign exchange amount has
been calculated the cash / security will be automatically populated to the
corresponding Field. For Security –Driven REPOs PRINCIPAL.AMOUNT 1
= TOTAL.SETTLEMENT and TOTAL.SETTLEMENT = GROSS.AMOUNT
+ ACCRRUED.INT.AMT (being market value of security) *
SC.INIT.MGN.RTE * FX.RATE .When an initial margin (Haircut) is used this
is taken into consideration in deriving at the TOTAL.SETTLEMENT amount.
The forward price is calculated in accordance with the security chosen, for
example if the security currency is USD and the cash currency is GBP the
forward price is be reflected in the security currency. This Field still has the
current option to enter a forward price manually with T24 recalculating the
required Fields. Principal repo cash amount (In cash CCY) = Market value of
security * initial margin *FX Rate. Principal repo cash amount ( In cash CCY)
= cash in CCY to be settled on start date . Principal repo cash amount + repo
interest ( subject to margin call, if any , in Cash CCY) = cash in CCY to be
settled on maturity date.

T3TRP - Repo - R14 43

 When a REPO trade is done, securities move out from the
BANK.PORTFOLIO to the MARGIN.PORTFOLIO of the Counterparty
In a RESO, securities flow into the MARGIN.PORTFOLIO from the portfolio
of the Counterparty, which is usually not maintained by the bank
For the forward leg of a REPO transaction, the SECURITY.TRANSFER
record is created on the VALUE.DATE or ‘n’ number of days before the
VALUE.DATE depending on the value of ‘n’ that has been set in either the
DAYS.DELIVERY Field of the REPO transaction or DAYS.PRIOR.EVENT
Field in the RP-0140 record in EB.ACTIVITY

T3TRP - Repo - R14 44

 The SECURITY.POSITION will get updated on authorisation of the
SECURITY.TRANSFER record . The authorisation happens automatically
when the REPO transaction has been authorised.
If the Field UPDATE.SC.POS.SOD in REPO.PARAMETER is set to ‘YES’,
then the processing of the SECURITY.TRANSFER and the update of the
SECURITY.POSITION file takes place as under:
The SECURITY.TRANSFER and the resulting SECURITY.POSITION
records pertaining to the forward leg of the REPO transaction will be created
immediately on authorisation of the REPO transaction, regardless of the
VALUE.DATE or any value in either the DAYS.DELIVERY Field of the
REPO transaction or DAYS.PRIOR.EVENT Field in the RP-0140 record in
EB.ACTIVITY.

T3TRP - Repo - R14 45

 ST.CONTRACT.ID The security side of the REPO contract is processed by
raising a SECURITY.TRANSFER deal for each security detailed on the REPO
contract. Once the REPO contract is authorised, the keys to those
SECURITY.TRANSFER deals that relate to the authorised securities, i.e. those
in the "old" security Fields, are stored in this Field
ST.UNAU.CONT.ID Field is used when securities are defined in the REPO
contract, SECURITY.TRANSFER deals are raised to effect the movement of
the securities. When the REPO contract that has changed the securities
information is unauthorised the keys to those SECURITY.TRANSFER deals
are held in this Field.
ST.REVERSE.ID Field is used for the security side of the REPO contract is
processed by raising a SECURITY.TRANSFER deal for each security detailed
on the REPO contract. When a substitution of securities is effected, a
SECURITY.TRANSFER deal is raised to back out any securities that have
been substituted. When the substitution is authorised, the keys to these
contracts are held in this Field. When the substitution is unauthorised, the keys
to these contracts are held in the ST.UNAU.REV.ID Field.

T3TRP - Repo - R14 46

 ST.UNAU.REV.ID Field is used when a substitution of securities is effected, a
SECURITY.TRANSFER deal is raised to back out any securities that have
been substituted. When the substitution is unauthorised, the keys to these
contracts are held in this Field.
ST.HISTORY.ID Field is for the security side of the REPO contract is
processed by raising a SECURITY.TRANSFER deal for each security detailed
on the REPO contract. Where a substitution of securities is effected, the
original transaction references for the SECURITY.TRANSFER deals are held
in this Field. The transaction references held in this Field are no longer a pert
of the REPO contract, and are held purely for information purposes.

T3TRP - Repo - R14 47

 Since the SECURITY.TRANSFER record will be created (but
SECURITY.POSITIONS will be updated only on the maturity date of the
REPO), it is necessary to maintain a list of SECURITY.TRANSFER Id’s for
which the position needs to be updated. To do this a live file,
RP.SCTR.SCHEDULES, is maintained. The id of the records in this file is the
date. The system will record the id’s of all the SECURITY.TRANSFER
records for which the position needs to be updated on a particular date.

T3TRP - Repo - R14 48

 When processing an OPEN REPO, the maturity date will accept an input of
‘0’. In open REPO’s, the interest accrued on the PRINCIPAL.AMOUNT.1 is
capitalized on a daily basis. This is reflected by the interest being added to the
PRINCIPAL.AMOUNT.1 on a daily basis. The rate of interest may be changed
during the tenure of the REPO.
When a maturity date is fixed, it should be input in the MATURITY.DATE
Field. This will cause the interest to be calculated from the date of input till the
maturity date and this amount will be populated in the INTEREST.AMOUNT
Field. The PRINCIPAL.AMOUNT.2 Field also gets populated with the
maturity value of the contract.

T3TRP - Repo - R14 49

T3TRP - Repo - R14 50
T3TRP - Repo - R14 51
T3TRP - Repo - R14 52
T3TRP - Repo - R14 53
T3TRP - Repo - R14 54
T3TRP - Repo - R14 55
T3TRP - Repo - R14 56
T3TRP - Repo - R14 57
 For setting up limits in REPOs, the required LIMIT.REFERENCE record is
needed for the REPO. Three limit reference records should be set up for use in
the REPO module.
REPO product limit , REPO contracts and Reverse REPO contracts
A REPO contract is essentially a loan of securities and a deposit of cash.
However, the Bank may see the loan of securities to the counter party as a
potential risk. It may wish the T24 Limit processing to treat it as if it were a
loan – thus decreasing the available limit.
A RESO contract is always viewed as a risk to the Bank, and updates the T24
Limits system accordingly i.e. as a loan.
At the value date of the contract, the REPO application updates the T24 Limits
system with the amount defined in PRINCIPAL.AMT of the REPO contract.
Upon maturity of such a contract, this limit update is backed out.
LIMIT.REFERENCE records set up as above need to be added to the MM
application also

T3TRP - Repo - R14 58

 If in a REPO transaction the REPO.TYPE chosen is BSB or SBB, only one
child contract is created. The MM.MONEY.MARKET deal does not get
created in a BSB or SBB transaction and the cash side to the REPO transaction
is handled through SECURITY.TRANSFER itself. Since in Buy / Sell Back
and Sell / Buy Back REPO transactions the cash component is also handled
through the SECURITY.TRANSFER, on input of a value in the
NEW.SEC.CODE Field, the nominal's are calculated based on the price for
that security found in the LAST.PRICE Field in the SECURITY.MASTER. A
check is performed to see whether the value of the security (i.e. the
DIRTY.PRICE x NEW.NOMINAL) exactly equals PRINCIPAL.AMT.1. If
not, the system will change the CLEAN.PRICE and the DIRTY.PRICE so that
the value of the securities will always be equal to the PRINCIPAL.AMT.1.If
the user manually changes any of the price Fields in a REPO transaction, the
system will recalculate the nominal's so that the value of the securities will
always be equal to the PRINCIPAL.AMT.1. The value of any coupon payment,
during the tenure of the REPO contract, on the security used in the REPO
transaction, is factored into the forward price of the REPO transaction.
Therefore, for BSB and SBB transactions, there is no need to transfer the
coupon amount by means of a FUNDS.TRANSFER. Currently the system can
handle situations where a single coupon payment straddles the tenure of the
REPO contract. Where multiple coupon payments straddle the tenure of to the
REPO contract, the user will have input the FWD.PRICE manually.

T3TRP - Repo - R14 59

T3TRP - Repo - R14 60
T3TRP - Repo - R14 61
T3TRP - Repo - R14 62
 REPO.POSITION file holds all security positions that have been “sold” under
a REPO contract from the Bank’s own book(s).
This is a ‘LIVE’ file. This gives an overall position which the Bank have
Repo's out to date. The REPO contracts that build up the REPO.POSITION are
kept in the REPO.POS.CONCAT file in which the user can drill down to the
contracts if required. The securities Repo's out are also recorded on the Field
REPO.NOMINAL on the SECURITY.POSITION file. This is used in the
portfolio REPO valuation enquiry (SC.VAL.REPO) to show the net holding of
the securities and to affect an override to the sale of securities Repo's out.

T3TRP - Repo - R14 63

 RESO.POSITION file holds all security positions that have been received by
the Bank under its Reverse REPO transactions.
This is a ‘LIVE’ file. This shows the Bank’s overall Reverse REPO position to
date. The Reverse REPO contracts that build up the REPO position are kept in
the RESO.POS.CONCAT file in which the user can drill down to the contracts
if required. The securities received under trilateral Reverse REPO are also
recorded on the new Field TRILATERAL.RESO.NO on the
SECURITY.POSITION. This is used to block the sale of any trilateral reverse
REPO holdings.

T3TRP - Repo - R14 64

 The accounting events on the date of the transaction a, daily accrual and
maturity date for a REPO transaction are shown here.

T3TRP - Repo - R14 65

 The accounting events on the date of the transaction and, daily accrual for a
RESO transactions are shown here

T3TRP - Repo - R14 66

 The accounting events on the maturity date of the transaction for a RESO
transactions is shown here

T3TRP - Repo - R14 67

 The accounting events on the date of the transaction and, daily spread accrual
for a CUSTOMER REPO transactions are shown here

T3TRP - Repo - R14 68

 The accounting events on the maturity date of the transaction for a
CUSTOMER REPO transactions is shown here

T3TRP - Repo - R14 69

 The accounting events on the date the spread is received for a CUSTOMER
REPO transactions are shown here

T3TRP - Repo - R14 70

T3TRP - Repo - R14 71
T3TRP - Repo - R14 72
T3TRP - Repo - R14 73
T3TRP - Repo - R14 74
 REPO uses the Soft Delivery mechanism. The main concept of Soft Delivery
is to define each different stage in the lifecycle of a contract as a discrete
event, by means of defining Activities on the file EB.ACTIVITY. Each of
these events will, by necessity, be unique to the Application.
Five application specific Activities are released with the REPO module.
Populate the DAYS.PRIOR.EVENT Field on these records according to the
business needs.
For every advice type in EB.ACTIVITY, details are stored in EB.ADVICES .
The records can be changed or create new ones and delete unused ones
according to your own requirements.

T3TRP - Repo - R14 75

 RP.SCTR.UPD.SCHEDULES file stores REPO record ID’s, which require the
delivery messages to be generated at a later date for the far leg security
movements.
This is a ‘LIVE’ file
The file is only updated if the Field UPDATE.SC.POS.UPD is set to “YES” in
REPO.PARAMETER.
It is keyed on the date that SECURITY.TRANSFERS will be generated.
When the record is processed REPO.POSITION, RESO.POSITION and
SECURITY.POSITION records are updated.

T3TRP - Repo - R14 76

 Three system wide message classes are released with T24 and they should be
authorised as required. They are Advice, Confirmation and Payment
The REPO module supports the following SWIFT messages:
MT540 – Receive Free
MT541 – Receive Against Payment
MT542 – Deliver Free
MT543 – Deliver Against Payment
MT518 –Market-Side Securities Trade Confirmation
MT515 –Customer Side Securities Trade Confirmation

T3TRP - Repo - R14 77

 A REPO contract updates many areas of T24 – cash side entries and delivery,
transfer of securities, etc. In addition, a number of reports, enquiries and
actions may be performed on the margin portfolio, as well as the banks own
account portfolio. Enquiry REPO.ENTRY.LIST is intended to allow users to
view the updates created from any given REPO contract to run these enquiries,
and to perform certain actions.
Enquiry REPO.UNAU.ENTRY.LIST is similar to REPO.ENTRY.LIST, but is
run on unauthorised REPO contracts.
Enquiry SC.VAL.REPO is used to run the valuation of the margin portfolio
and should be used to determine if a margin call is required (or is to be
expected from the counterparty). .This enquiry may be initiated from the
REPO.ENTRY.LIST Enquiry.

T3TRP - Repo - R14 78

T3TRP - Repo - R14 79
 Two multi value sets are present on the REPO contract to allow the processing
of the security side of a REPO contract. The “old” Fields (OLD.SEC.CODE,
OLD.NOMINAL etc) show those securities that currently form part of the
REPO contract. These Fields are no input. The new Fields (NEW.SEC.CODE,
NEW.NOMINAL etc) show securities that will form part of the REPO contract
once the deal has been authorised. It is these Fields that the user keys into to
define the securities that form part of the REPO contract, and these Fields that
are used to process any modification to the securities involved in the contract.
Such modifications include:
Increase in Nominal
Decrease in Nominal
Addition of a security
Removal of a security
Substitution of a security

T3TRP - Repo - R14 80

 The “new” Fields are an “after image”. In effect, once authorised, the “new”
Fields are moved to the “old” Fields – and the securities defined there form the
securities that form part of the contract. The “new” Fields contain the
information set in the “old” Fields, and act as a template for the modification
of the securities. It is important to note that the ability to increase / decrease
the nominal of a given security should NOT be used to satisfy a margin call.
Initially the securities are added to the REPO contract. At this stage the
contract has not been authorised and the existing security Fields are blank.
There have been no movements of securities. Once the REPO contract is
authorised and the movement of securities has taken place, the existing
securities Fields are filled in. NB. The New Securities Fields are still
populated to allow the easy processing of addition, removal or substitution of
the securities.
To remove a security from the REPO deal, delete the multi-value set in the
New Securities section: Once the REPO contract has been authorised, the
removal of the security is reflected in the existing Security Fields.
By expanding the new Securities multi-value group, an additional security may
be added to the REPO contract. An increase in nominal is achieved by simply
changing the nominal defined. By replacing the security defined in the new
Security Fields, a substitution may be effected: Once the REPO contract is
authorised, substitution of the security is reflected.

T3TRP - Repo - R14 81

T3TRP - Repo - R14 82
T3TRP - Repo - R14 83
T3TRP - Repo - R14 84
T3TRP - Repo - R14 85
 The margin accounts are used to record any margin calls if required. You have
the option to define the required account or use the memo account. You can
define postings to be used by establishing various accounts on the
SEC.ACC.MASTER. Several accounts in differing currencies may be used if
required. Normally, margin calls are made in the reference currency. If the
currency of the security does not have an account specified in the margin
portfolio, then the first account defined is used as the default.
SC.INIT.MARGIN.RATE allows the user the option to select what margin rate
is to be applied to each security/multiple securities that are entered. This Field
will only become active if the option of SECURITY has been selected in the
Field TRANS.TYPE
Once the user has selected which type of security they wish to REPO and the
amount of nominal, T24 will default the clean and dirty price, this information
will then populate the Field PRINCIPAL.AMOUNT.1.

T3TRP - Repo - R14 86

 NEW.DEPO Field is the depository where the security defined in the
SEC.CODE Field. The securities that will form a part of REPO or Reverse
REPO contract, are defined in the Field.
SUB.ACCOUNT Field contains a sub account which can be specified for the
depository entered in NEW.DEPO. Any input made must be defined as a sub
account on the CUSTOMER.SECURITY record for the depository.
NEW.CU.ACCT.NO Field is the margin account, defaulted from the
MARGIN.PORTFOLIO for regular REPO or from the CUST.PORTFOLIO for
Customer a REPO according to the repo currency is held here. The securities
that will form a part of REPO or Reverse REPO contract, are defined in the
Field.
SC.INIT.MGN.RTE Field is the initial margin of the Security, where
applicable. The initial margin of a REPO contract can be used as a device to
undervalue the securities involved; hence to cover the risk of the adverse
movement of the securities which may arise before a margin call can be paid.
This Field is used to calculate the SC.INIT.MGN.AMT from the
GROSS.AMOUNT & ACCRUED.INT.AMT Fields.
SC.INIT.MGN.AMT Field is the amount of Initial Margin that is related to the
Security in this multi-value. This Field will only get populated if the
TRANS.TYPE is set to "SECURITY" & the SC.INIT.MGN.RATE is set.

T3TRP - Repo - R14 87

 If the user has populated the SC.INT.MGN.RATE the amount shown in
PRINCIPAL.AMOUNT.1, will be reduced by the new calculation method.
When populating the SC.INT.MGN.RATE the user will enter the percentage.
The amount of the margin for example 5%. T24 will then calculate the new
principal amount as follows under the e two methods of calculation
STANDARD, or GMRA.
Standard Method: Cash amount = market value of security x margin
= Nominal x dirty price x margin = 1,000,000 x 96 x 0.95 = 912,000
The buyer has demanded a 5 percent haircut, meaning they intend to transfer
cash, which is 5 percent less than the market value of the security.
GMRA Method: Cash amount = market value of security x margin
= Nominal x dirty price x margin = 1,000,000 x 96 x (1 /1.05) = 914,285.71
The logic behind this procedure will be that T24 will use the clean price stored
in the SECURITY.MASTER file plus any accrued coupon interest on the
security thus deriving at the dirty price. The final cash proceeds will then be
calculated against the dirty price, less the initial margin in accordance with the
haircut method selected by the user.
No additional entries will be required for the initial margin as the cash
received or lent has been reduced to reflect the margin amount.

T3TRP - Repo - R14 88

 The counterparty margin portfolio is updated by the REPO application and it is
this portfolio that is used as the basis for the margin processing. If the same
counterparty is involved in both REPO and RESO transactions with the Bank,
two margin portfolios are needed to record the transactions separately.
Enquiry SC.VAL.REPO is used to perform a valuation of the margin portfolio.
Based on this information, the bank can decide whether to make a margin call,
or whether one is to be expected from the COUNTERPARTY of the REPO
contract.
Since all REPO contracts and RESO contracts will be recorded in different
portfolios, the margin valuation enquiry should only be run over RESO
portfolios to establish which counter parties the Bank may wish to call
additional cash margins.
SC.VAL.REPO enquiry therefore allows the Bank to view the margin call as
either a net REPO position or a net RESO position, derived using all contracts
with a given counter party.

T3TRP - Repo - R14 89

 Margin Calls may be made in terms of (1) a change in the Principal Amount –
Cash Margin Calls (2) a change in the number of Nominal's or (3) a
substitution of the security with or without a change in nominal's may also be
constitute a margin call.
To effect a Cash Margin Call, i.e. by making a change in the Principal, the user
will need to key in the amount by which the Principal is to be increased or
decreased in the PRIN.INCREASE Field. This Field allows input only in an
authorised record. A negative value may be input in this Field to obtain a
decrease in the original Principal.

T3TRP - Repo - R14 90

 When a value is input in the PRIN.INCREASE Field, two other Fields
associated with the margin call become inputtable. These are the
MGN.CALL.EFF.DATE Field and the SEND.PAYMENT Field. The
MGN.CALL.EFF.DATE Field will hold the date on which the margin call
comes into effect. The effective date must fall between the VALUE.DATE and
the MATURITY.DATE of the contract. The user may input a back valued date
provided it falls between the VALUE.DATE and the MATURITY.DATE of the
contract.
The MGN.CALL.EFF.DATE Field becomes mandatory if there is a value in
the PRIN.INCREASE Field, or, a change has been made, in an authorised
record, to the NEW.SEC.CODE or NEW.NOMINAL Fields.
To effect margin calls in Securities, the user has the option of replacing the
security with one of higher value or increasing the nominal's. Any change
made to either the NEW.SEC.CODE Field or the NEW.NOMINALS Field will
make the MGN.CALL.EFF.DATE and the MGN.DELIV.INSTR Fields
inputtable.
These Fields are mandatory for a margin call settled in securities. The Field
MGN.DELIV.INSTR will accept only instructions that do not entail any
payment.

T3TRP - Repo - R14 91

 The Fields MGN.CALL.EFF.DATE and the MGN.DELIV.INSTR are
mandatory for a margin call settled in securities. The MGN.DELIV.INSTR
Field will accept only instructions that do not entail any payment.
If the margin call has been made by changing the number of nominal's, the
delivery instructions for the movement of securities will be generated for the
difference between the old value in the NEW.NOMINAL Field and the
changed value.

T3TRP - Repo - R14 92

 NETTING.AGREEMENT application is used for defining counterparties for
whom netting has to be defined.
It can be defined including or excluding a currency. The validity period of the
agreement can be defined. The record Id now consists of the customer,
followed by “.”, followed by the 2 letter module Id.
For example 100550.RP indicates customer 100550 in the RP module

T3TRP - Repo - R14 93

 When a transaction is input in REPO application for such a counterparty,
system defaults group status as YES. It can be manually set to NO.
No delivery message generated at this stage. Accounting entries raised to
suspense category defined in the parameter set up in the Field ENT.NET.SUSP
SC.GROUP.TRADES application allows multiple transactions to be grouped
together. Once a transaction has been authorised ,the MSG.REF Field will be
populated if a delivery message was created. The STMT.NOS Field will be
populated if accounting entries were made.
SC.GROUP.TRADES is to be input with values for selection criteria. The
value/maturity date to be defined here for the netting. Auto/manual selection
method for the REPO contracts to be set. If Auto, then system will match
criteria, and select REPO contracts matching the selection and Group status as
YES. If Manual, contracts will be user input.

T3TRP - Repo - R14 94

 Accounting is available for view through enquires at unauthorised stage. If the
value date for the accounting is greater than the bank date the accounting will
be generated as forward entries.
A close of business job COB.SC.GROUP.TRADES.ACCOUNTING will
delete the forward entries and raise real accounting entries when value date is
reached.
When SC.GROUP.TRADES is authorised, system generates messages for the
Depositories populating the Field MSG.REF. ENT.NET.SUSP Field is used to
determine which account the netting will be reversed and accounting entries
raised.

T3TRP - Repo - R14 95

T3TRP - Repo - R14 96
T3TRP - Repo - R14 97
T3TRP - Repo - R14 98
T3TRP - Repo - R14 99
T3TRP - Repo - R14 100
T3TRP - Repo - R14 101
T3TRP - Repo - R14 102
 The original owner can receive directly the payment of the coupon for his
REPO positions. When the ENTITLEMENT record of the Bank’s own
portfolio is authorized then separate REPO entries can be posted on a special
account per REPO transactions. The SPLIT.DEBIT.CPN Field should be set to
‘YES’ and the NOSTRO.ACCOUNT updated for the REPO application with
the Nostro’s REPO account. The REPO transactions are detailed in the
RP.ALT.NOSTRO record keyed on the DIARY ID.The information can be also
found at the DIARY level where there is the total cash amount of the REPO
entries.
The RESO entries can be also posted on a separate account. This is done if the
ENT.CPN.SUSP Field is updated in the REPO.PARAMETER record. In this
case, the ACCOUNT.NO Field is updated with this RESO account in the
ENTITLEMENT record of the RESO portfolio.

T3TRP - Repo - R14 103

T3TRP - Repo - R14 104
T3TRP - Repo - R14 105
 It is possible to process Stock Borrow lending transactions for customer and
own book positions through the REPO module
When a customer sells short through a SEC.TRADE , it can be covered either
through a SEC.TRADE or through borrow. If the customer requires the
option to cover the short position via a borrow rather than a close out using a
SEC.TRADE, then 2 transactions are recorded in REPO as under-
Market borrow from external counterparty to the wash portfolio
Internal lending from the wash portfolio to the customer
Likewise the stock lending can be done for a long position instead of a
SEC.TRADE /

T3TRP - Repo - R14 106

 The characteristics of different types of Repo contracts are defined through
REPO.TYPE table . The records available on this file are referenced from the
main contract file REPO.
The TRANSACTION.INDEX determines whether the contract is treated as a
Repo (a cash deposit) or as a Reverse Repo (cash loan), and is linked to the
PRODUCT.CATEGORY that defaults onto the contract itself.
DEAL.TYPE Field IS STOCK.BORROW.LEND.
These DEAL.TYPE's are available to both REPOs and REVERSE REPOs.
GENERATE.FT Field option is select YES or NO. When the user has selected
the option of YES the cash margin process messaging associated with this
REPO.TYPE will be handled via FUNDS.TRANSFER, with the generation of
the SWIFT linked to the original contract. No MM.MONEY.MARKET
contract will be generated. The accounting will be generated by associated
SECURITY.TRANSFER.
FT.TRANS.TYPE Field used in conjunction with GENERATE.FT to assign a
value to the Field TRANSACTION.TYPE in the FUNDS.TRANSFER
contracts.

T3TRP - Repo - R14 107

 REPO.TYPE is BORROW and LEND with the deal type as
STOCK.BORROW.LEND
INT.BORROW and INT.LEND with the deal type as INTERNAL. In this case
the product category need not be specified
REPO.PARAMETER is a top-level parameter file that is keyed by the id of
the company to which the parameter record refers.
It holds the definitions of the valid portfolio suffixes for the counterparty
margin portfolio, the booking method of the initial margin,
the limit update treatment for REPO contracts and the no. of days post
maturity that contracts are moved to history
Create a portfolio for the wash account and the counterparty with the above
suffix.

T3TRP - Repo - R14 108

 For the Stock borrow/lend functionality in REPO the following trades are to be
input. Market borrow from external counterparty to the wash portfolio. This
creates a RESO.POSITION for the wash portfolio .Internal lending from the
wash portfolio to the customer . This creates a RESO.POSITION for the
customer (as the trade is a borrow for the customer) and a REPO.POSITION
for the wash portfolio.
The SECURITY.POSITION for wash portfolio shows ZERO closing balance
with borrowed/lent nominal under RESO/REPO positions and the customer
position reflects the short position along with the borrow amount under
RESO.POSITION.

T3TRP - Repo - R14 109

 If we assume for this example that Customer 1 has sold short 100 IBM shares
via a SEC.TRADE and requires the option to cover this position via a borrow
rather than a close out via a further SEC.TRADE.
Trade 1 – borrow to wash with an external counterparty / broker –Market
Trade
Trade 2 – lend to an internal customer with portfolio as counterparty / broker -
Internal trade
T1 and T2 are independent transactions. There may be multiple T1s against
multiple T2s, however there is no direct link within the system. Manual
control ensures that positions borrowed offset positions lent i.e. the control
account (wash position) should be at 0. The booking of a T2 is not dependent
on the booking of a T1 and vice versa. Features of the trades are as follows.
The trades can be open ended. Early maturity of the trades is also possible. For
partial return of the borrowed/lent amount, margin calls can be used. Message
is generated to the depository and broker for the market trade which can be
suppressed by the user. The trades are independent transactions. Can be
multiple T1s against multiple T2s, however there is no direct link within the
system. Manual control ensures that positions borrowed offset positions lent
i.e.. the control account (own book / wash position) should be at 0.

T3TRP - Repo - R14 110

 There is no link between trade 1 and trade 2 and there is no requirement to
have a T1 and T2, which offset each other.
For example, a client may return 100 shares on trade 2, and another client then
borrows 100 with another T2. There is no requirement for a return T1. In this
case the positions net out but this is not necessary: the position may be
maintained as a pending position between T2 and T1.
For example, client x returns 100 and client y borrows 60. The “own book /
wash” control account will have a position of 40, which would be manually
closed by users through T1 or T2 transactions.

T3TRP - Repo - R14 111

 The client position is not moved as a result of Trade 2. For example, if they are
short and borrow to cover this, they remain short (with a borrowed position).
Trade 1 produces an Agent/Depository instruction in MT 540 / 542 format.
Generally this is FOP, but this may also be DVP transactions. For all SBL
transactions, it must be possible to suppress the broker, depository messaging
with a flag on the transaction with BR/DEP.ADVICE.REQ type Fields. No
depository messaging is required for trade 2, as this is an internal trade and we
are only switching between security positions wash – customer. Trade 2
booking will tell us not only client, but also portfolio (where long and short
portfolios are held for the client).

T3TRP - Repo - R14 112

 The traded borrows and loans may or may not offset each other
The “own book / wash control” portfolio indicates where there are differences
by the presence of a position.
Can have settlement differences, which would arise because, for example,
although T2 has settled contractually or actually (using AUTO.CUS.SETTLE),
T1 is still unsettled.
T2 returns will be received with instructions as to which position should be
returned (in the case of multiple borrows making up the borrowed position).
P&L between Trade 1 and Trade 2 will be calculated outside the scope of T24
functionality. Fees are calculated outside the scope of T24 functionality.

T3TRP - Repo - R14 113

 The application allows the user to amend the maturity date on fixed term
trades.
The user has the option to go back into the original trade and enter a new
maturity date. This will then trigger the required settlement / SWIFT messages
in accordance with the lead time.
The accounting and the security positions will be updated with the early close
out by the current functionality of a SECURITY.TRANSFER record.
If SOD maturity or both is set it will not be possible to set early maturity as
today as this would have had to have been actioned as part of the start of day
COB.

T3TRP - Repo - R14 114

 Margin calls (stock returns/stock increases) for REPO contracts with no
maturity date only applies to those REPO contracts where the REPO.TYPE
Field DEAL.TYPE is STOCK.BORROW.LEND or INTERNAL. It is also
possible to specify the NEW. NOMINAL as zero, indicating that all the stock
is to be returned, the restriction dependent on the REPO.TYPE Field
DEAL.TYPE also applies, i.e. the nominal can only be set to zero for
STOCK.BORROW.LEND or INTERNAL trade types. It will not be possible
to initiate a REPO contract with the stock specified but with zero nominal. All
contract initiations must include a nominal value greater than zero if the stock
is specified There are no pre-determined order checks on any margin calls. If a
margin call is entered then it is not necessary the trade date and/or value date
for this call is greater than the previous margin call. The only restriction made
is against the REPO contract, i.e. the trade date and value date of the margin
must not precede the contract dates. Each margin call must be input and
authorised before the next margin call can be entered. The existing margin call
Fields are to be used and are single value Fields only.

T3TRP - Repo - R14 115

 If the maturity date is specified on a previously open contract or a contract is
early matured then the date entered is checked to ensure that the maturity date
is greater than or equal to any margin call value dates that have been entered
but not cancelled.
MGN.CALL.TRD.DATE Field is used in the corresponding
SECURITY.TRANSFER record and used on outgoing delivery messages. It is
not be mandatory to populate this Field when making a margin call but if it is
not specified explicitly then the REPO contract trade date will be used. It is
not possible to input a margin call trade date that precedes the contract trade
date. The margin call value date must also not precede the contract value date.
If a margin call is made on a REPO contract where the CONTRACT.STATUS
is FWD then no SECURITY.TRANSFER records will be generated for this
call and the amendment will only be seen through the difference between
contract history records. FWD contracts are those contracts whose initial
SECURITY.TRANSFER has not yet been generated. Such forward contracts
will then result in a single delivery message being generated for the net
nominal when the close of business job generates the contract initiation.
However if EB.ACTIVITY is set so that the contract status is CUR then
SECURITY.TRANSFER will be generated for the margin call (as the contract
initiation will also have been generated).

T3TRP - Repo - R14 116

 If YES has been selected T24 will reverse this SECURITY.TRANSFER with the generation of the
required SWIFT cancellation message (MT54X Cancel) and update the SECURITY. POSITION to
reflect the cancellation of stock movement without the generation of a further SECURITY.TRANSFER
record.
The Field NEW.NOMINAL will be automatically re populated with the nominal amount prior to the
capturing of the nominal amount (decrease / increase) of the margin call. Cancellation of instructions on
the maturing / return side of the transaction for FOP and DVP trades that are open ended only. FOP Open
Trades: If a YES has been selected in the Field CANCEL.MAT.CALL, the above processing logic will
be followed of cancelling the associated SECURITY.TRANSFER with the correct generation of the
required SWIFT and update to the security position. To close out an open trade, T24 would have been
populated in the Field MATURITY.DATE with an agreed close out / return date.
If YES has been populated in the Field CANCEL.MAT.CALL T24 will access the history record and
populate the MATURITY.DATE with the previous value of Zero, confirming the trade has been returned
to its previous status of open ended.
DVP Open Trades: The same processing logic as applied to FOP trades will be used for DVP trades with
the additional functionality of reversing the FUNDS.TRANSFER, that has been generated for the posting
of the accounting entries for the cash amount. T24 views the FUNDS.TRANSFER ID stored in the Field
FT.TRANS.TYPE, which has been generated for the account posting for the maturing / return leg, and
reverse these accounting entries.
The Field PRINCIPAL.AMOUNT.2 will be automatically re populated with the cash amount prior to the
close out / return date.T24 will also populate the MATURITY.DATE with the previous value of Zero,
confirming the trade has been returned to its previous status of open ended. The Field
CANCEL.MAT.CALL will only become effective providing the option of YES has been selected in the
Field GENERARTE.FT in the REPO.TYPE

If an open trade is closed out by entering a maturity date this user has the
option to cancel the last change and return the trade to open.
The option of YES will only cancel the last action made. To cancel a specific
SECURITY.TRANSFER the user must enter the id, this can be any of the
previous calls made, and providing the original contract security nominal will
not be reduced below zero. The user cannot cancel margin call on a term trade

T3TRP - Repo - R14 117

 that would return the security nominal to zero, error message will be displayed.

T3TRP - Repo - R14 117

 A special process relating to cash corporate actions allows the user to capture
specific borrow and lending rates per REPO contract.
The Fields SBL.DIV.PROC, DIV.CONTROL.CAT and DIV.TRANS.TYPE
need to be populated to activate this functionality.
The Field SBL.DIV.RATE is used to record these specific borrow and lending
rates. Then based on the customers overall depository position and taking into
account all settled borrow and lending transactions this rate is used in the final
cash calculation for the customer and counterparty / brokers ENTITLEMENT
record.
In the event of the client selling short, he may not be able to borrow sufficient
stock to cover the entire short position, and hence this would result in an
under-borrow situation. Similarly, he may actually wish to borrow more stock
than is actually required to cover the short position, and hence this would
result in an over-borrow situation.
When a cash dividend is paid, the client is debited for any borrows (as at
record date) using the appropriate dividend borrowing rate(s).
The overall net position of the client is also determined. If the client has over-
borrowed, i.e. he has a net long position, then the dividend on this position is
calculated as if it were a normal long position (using existing client with-
holding tax rates).
If, however, the client has a net-short position, i.e. he has under-borrowed, then
the dividend on this position is calculated using the maximum tax rate

T3TRP - Repo - R14 118

 applicable for that country, and is stored at agent/depository level. The Field
MAX.TAX.RATE in the CUSTOMER.SECURITY record stores this value per
depository level.

T3TRP - Repo - R14 118

 SBL.DIV.RATE Field will be used to enter the dividend borrowing rate for
borrow or lending transaction in the REPO application. The value represents a
percentage so for example if a normal entitlement of cash was calculated as
£100 then the recalculation after applying the above SBL rate would be £110.
The SBL contract Dividend Rate has an associated EFFECTIVE.DATE Field
which allows Corporate Action processing to select an appropriate DBR based
on the Record Date contained within the DIARY record which drives the
Corporate Action processing both for new events and for reruns of existing
SBL contract related actions.
SBL.DIV.RATE and SBL.EFF.DATE are linked sub-valued Fields related to
each of the multi-valued
When a Corporate Action is initiated the RECORD.DATE will determine
which ruling Dividend Rate is extracted from the relevant SBL contracts. If
there is no RECORD.DATE then the EX.DATE from the DIARY will be used

T3TRP - Repo - R14 119

 BORROW.AMT holds the amount payable by the client for the dividend on
his borrowed position.
It is calculated by the system using the formula Borrowed Position x Dividend
Rate x Dividend Borrowing Rate ,
Borrowed Position will be recorded in the BORROW.NOMINAL Field of the
ENTITLEMENT record. The dividend Rate will be recorded in the RATE
Field of the associated DIARY event. The dividend Borrowing Rate will be
recorded in the SBL.DIV.RATE Field of the underlying borrow transaction
entered in the REPO application

T3TRP - Repo - R14 120

 LENDING.AMT file holds the amount payable to the client for the dividend
on his lent position.
Automatically calculated by the system using the formula Lent Position x
Dividend Rate x Dividend Borrowing Rate Lent Position will be recorded in
the LENDING.NOMINAL Field of the ENTITLEMENT record. Dividend
Rate will be recorded in the RATE Field of the associated DIARY event.
Dividend Borrowing Rate will be recorded in the SBL.DIV.RATE Field of the
underlying SBL lend transaction entered in the REPO application
LENDING.NOMINAL
This Field will be used to display the client’s lent position as at the record date
of the associated corporate event. This Field will be automatically calculated
and updated by the system.

T3TRP - Repo - R14 121

 SBL.QUALIFY.HOLD Field will contain the client’s net outstanding position.
When the client is borrowing, this will be calculated by the system using the
formula:
Ex-date -1 closing position plus Record-date settled borrowed position.
When the client is lending, this will be calculated by system using the formula:
Ex-date -1 closing position minus Record-date settled lent position

T3TRP - Repo - R14 122

 Corporate Actions(CA) are processed for zero position SBLs as well as over-
borrowing and over-lending cases
For example, we have the current option to reduce the nominal on any REPO
contract to zero by the use of margin increase/decrease facility.
The contract will remain in the “LIVE” file depending on the setting in
the REPO.PARAMETER Field DAYS.POS.MATURITY.
The CA process will therefore interrogate these trades and include only
the trades that had a nominal balance at the time the CA is run.
If however the balance was zero this will not be include in the
ENTITLEMENT produced by T24.

T3TRP - Repo - R14 123

T3TRP - Repo - R14 124
 We have so far seen
The parameter set up for the T24 Repo application
The various repo types and the deal types supported by the application
How the system handles various scenarios under Repo operations
The accounting, and delivery requirements
The connected enquiries

T3TRP - Repo - R14 125

T3TRP - Repo - R14 126