zapytanie ofertowe · web viewcashflow report for treasury deals split by currency, individual...

Appendix 1 to the RFP

REQUIREMENTS FOR DELIVERY, IMPLEMENTATION AND MAINTENANCE OF A FRONT OFFICE SYSTEM IN BANK OCHRONY ŚRODOWISKA S.A.

A. FUNCTIONAL REQUIREMENTS

These are functional requirements split by groups:

Group I – functional requirements for user desktop and transaction registration,Group II – functional requirements for liquidity position management,Group III – functional requirements for currency position management,Group IV – functional requirements for securities position and interest rate management,Group V – functional requirements for calculation of FX speculation result,Group VI – functional requirements for calculation of interest rate result,Group VII – functional requirements for customer transaction management, Group VIII – functional requirements for counterparty and issuer limit management, Group IX – functional requirements for market risk management and monitoring, Group X – functional requirements for regulatory reporting, Group XI – additional requirements for system operations.

B. INTEGRATION REQUIREMENTS C. TECHNICAL AND TECHNOLOGICAL REQUIREMENTS D. RFP SCOPE E. IMPLEMENTATION REQUIREMENTS

of 31

Terms and definitions

Name DescriptionCounterparty Bank, a financial institution which is a counterparty to a transaction, an issuer of

securities and CCP (Central Counterparty Clearing House)Customer Bank’s corporate customer serviced by the Structural Projects Office (BPS)Market data Data related to the curves of interest rate, prices of bonds, foreign currency

rates, reference rates. VaR A statistic that measures the maximum loss, over a specific period of time, with

a given probability, which the Bank may incur on open positions sensitive to changes of market factors.

BPV A unit of measure representing how transaction pricing may change following the change of interest rates by 1 basis point.

Currency Position

A currency position in each currency arising from an open FX position in the Bank, as at the end of the previous day and all transactions performed during the day by an interbank dealer (including transactions on the interbank market and transactions with non-bank customer dealers) and the branch position.

Branch Currency Position

A currency position in each currency arising from the balance of transactions conducted in Bank’s branches/ Corporate Centres (branch transactions) or other transactions related to accounting adjustments, including those related to loan loss provisions.

Bank’s FX Position

A currency position in each currency arising from Bank’s open FX position resulting from all the transactions (including interbank ones and, for instance, accounting adjustments). Bank’s FX Position is the sum of dealer and branch positions.

Total Position The maximum of sums of net long and short positions in all the currencies.

Def3000/TR A system for processing Back Office transactions. Integrated with internal systems (core transaction system, general ledger, data warehouse) and external systems (payment and confirmation clearing and reconciliation, statements, settlements with the depositary). The system provider is Asseco Poland S.A.

Def3000/CL A payment hub system processing Bank’s incoming and outgoing payments. This is an interface between bank’s internal system and various clearing chambers. The system processes (STP) SEPA, SWIFT TARGET2 and SORBNET2 payment messages, instant payments, particularly KIR-SRPN payments (Express Elixir). The system provider is Asseco Poland S.A.

BA Business Administrator, a user authorised to edit system parameters DFO Financial and Operational Risk Department BPS Structural Projects Office DFA Financial Markets and Analysis Department Nostro Monitor

An IT tool presenting the balance of Bank’s Nostro accounts

of 31

Purpose of implementation and functions of Front Office System

The system enables registration of transactions, position keeping, monitoring and calculation of positions, presentation of the currency position and interest position versus the limits, enables current liquidity management, results calculation, simulation of position and P&L changes, interest rate position management, market data feeds, handling of customer and counterparty limits, communication via relevant interfaces with systems popular in the financial market, trading platforms and Bank’s internal systems necessary for meeting the Front Office system requirements.

The system supports the following types of instruments: FX Spot, Fx Forward, FX NDF, FX Swap, FX NDF SWAP, FX Options Time deposits, cash deposits, REPO (including also Cross Currency REPO), REVERSE REPO, Buy Sell Back,

Sell Buy Back IRS, Basis swap, CIRS, FRA, OIS, Treasury bonds (fixed-rate, floating-rate, zero coupon, index-linked), treasury bills, money bills,

corporate bonds, own issues Credit lines, loans from financial institutions

Reporting Generating reports containing data related to counterparties, concluded transactions, transaction pricing, utilisation of individual types of limits, split by portfolios, currencies and transaction types.Registration of historical changes made to transactions, information on the original transaction and modifications made (e.g. change of notional, interest rate, exchange rate, dates, etc.)

Data import/ export The system will enable export/ import of:- transaction data - data related to utilisation of limits and P&Lcalculation - other required results/ positions

Limit control Real time automatic alerts of exceeded limits and exceeded transaction parameters. Summary reports of daily alerts.

of 31

A. FUNCTIONAL REQUIREMENTS

Group I - functional requirements for user desktop and transaction registration

Dealer desktop

Item Requirement Description of expected system functionality 1. Elements of FX Spot

Dealer desktop A desktop containing, in particular: Currency positions split by currencies Current utilisation of currency position limits Current utilisation of counterparty limits (possibility to check limits of a

given counterparty and to check utilisation of limits of all counterparties, including the sorting function (e.g. by current utilisation level)

Presenting transactions split by type and subtype and pending transactions

FX VaR monitoring Presenting daily, monthly, Year-to-Date FX results – versus current

exchange rates and current referential fixing (optional)2. Elements of Fixed

Income Dealer desktop

Current utilisation of counterparty limits (possibility to check limits of a given counterparty and to check utilisation of limits of all counterparties, including the sorting function (e.g. by current utilisation level)

Securities position (trading portfolio), including drill-down (down to transaction level).

Current BPV position split by securities and derivatives, tenors, curve types, position currency)

Current utilisation of BPV and VaR limits Current valuation of transactions in the interest rate trading portfolio Presenting pending transactions Presenting realised P&L (optional) Cost of carry Possibility to generate a list of historical/ daily changes (trading portfolio

transaction pricing, generated results, costs of carry) by the selected date or daily, monthly, yearly period split by securities and derivatives (optional)

3. Elements of Banking Book Dealer desktop

Securities position split by portfolio (Held to Collect and Sell as well as Held to Collect)

Current BPV position split by securities type and tenors Current BPV utilisation for securities split by portfolio (Held to Collect

and Sell as well as Held to Collect) Cashflow report for treasury deals split by currency, individual days and

tenors, including drill-down (down to transaction level) Tool for viewing Nostro accounts’ balances: view of the current balance

and projected balances for at least 5 working days (using an interface with Def3000/CL).

Daily, monthly, year-to-date results split by securities and derivatives, realized and unrealized interest income and costs of carry (optional)

Current utilisation of counterparty limits (possibility to check limits of a given counterparty and to check utilisation of limits of all counterparties, including the sorting function (e.g. by current utilisation

of 31

level) 4. Customer Dealer

desktop Desktop including, in particular: Blotter – real-time list of concluded transactions split by transaction

types – including margin presentation Mark-up for a given time period (day, month, year) split by individual

transactions, instruments, Customer (optional) Customer’s currency position as of a given date – present a list of

component transactions (optional) Information on the selected non-bank counterparty, particularly

identification password, list of proxies including phone numbers, list of signed contracts, LEI (possibility to import data from Def3000/TR).

Information on customer transaction parameters such as average margin, activity, transaction volume in base currency and settled currency (for selected period),

Information, per selected counterparty, on limits, limit utilisation and limit expiry dates

Presentation of pending and simulated transactions.5. Customer Dealer

desktop – Alerts Automatic alerts related to: exceeded limit result per transaction displayed in the ticket prior to validation. Warning against entering a transaction with a negative margin. Warning against using non-standard deviation from interbank

market transaction terms (optional) Warning against entering value date earlier than transaction

conclusion date or non-working date or date exceeding the available limit.

inactive LEI exceeded allowed transaction parameters generate reports on: utilisation of counterparty limits split by, for instance, counterparty,

currency or country. Result on a given instrument, customer, system user within a specific

time period.

of 31

Financial risk manager desktop

Item Requirement Description of expected system functionality 6. Default desktop

configuration Possibility to configure user’s desktop, particularly: displaying current VAR, BPV, currency position, selected limit exposures versus limits.

7. Alerts System will automatically display alerts when exceeding limit/s

8. Email notification upon exceeding limits (Optional)

Upon exceeding limits, the system sends an email with details to predefined recipients.

Transaction registration

Item Requirement Description of expected system functionality 9. Trade Ticket

configuration For transactions registered manually, possibility to set up a trade ticket template with automatically filled out default transaction data, e.g. transaction type, reference number, currency/ currencies, settlement account (SSI), transaction clearing date, transaction maturity date, etc. Transaction registration in accordance with legally required data regarding EMIR, MIFID II (APA, ARM), SFTR (detailed requirements included in “Group X - functional requirements for regulatory reporting”)

For transactions with a non-bank counterparty transfered to trading book (now, these are FX Spot, FX Forward, IRS deals), entering the reference rate as the basis for margin calculation according to an algorithm).

The system is to enable entering swap points (for FX Forward deals with a non-bank counterparty) from the interbank desk to the sales desk.

10. Transaction Import

For transactions concluded in external transaction systems and on platforms, automatic transaction import to the F/O system in real time.

Import from trading systems: Refinitiv (Thomson Reuters) in particular FXTrading, Bloomberg and platforms, particularly: Goldman Sachs, Barclays, BNP, DB- Autobahn, CitiVelocity, Credit Agricole, Societe Generale.

11. Transaction registration functions

Function: copy ticket, for the purpose of settlement, select any account from all accounts of the

Counterparty automatic calculation of the number of transaction days, automatic calculation of markup from transactions with a non-bank

Counterparty versus the reference rate handling of pending and simulated transactions when entering transactions, it will be possible to carry out limit utilisation

simulations 12. Add fields to

Trade Tickets (optional)

Add new fields to trade tickets (e.g. for the purpose of EMIR, MIFID II, SFTR, MIFIR reporting).

Possibility to send the added fields via a data interface to def3000/TR. 13. Pending

transactions These transactions will temporarily replace real FX Spot, FX Forward, IRS and securities deals which, for some reason, may not be finally registered. They

of 31

(TP) for FX Spot, IRS, securities

will be registered by the trader later once missing data is filled out, but pending transactions are to affect the currency and interest rate position (limit utilisation) until the trader accepts the transaction in the system.

14. Simulated transactions

Simulated transactions – this is a trial entering of a transaction to check the position/ limit values.

Possibility to enter several simulated transactions and check how they affect the limits/ position/ P&L/VAR/BPV taking into account all the simulated transactions (optional).

15. Changes of transaction terms

Modification of transaction terms: partial shortening, extension, complete or partial unwinding.

16. Reference transactions

Possibility to register reference transactions to customer transaction, e.g. to transfer the position to the trading book.Such transfer should be made at the reference rate downloaded automatically or entered manually (depending on how the Bank chooses to feed the market data during the day). The reference rate applies to the fixed rate of the transferred deal.

Reference transactions should be generated automatically for predefined derivative transaction types (now IRS) and the reference rate defined at the original transaction (fixed rate) – optional.

17. Market Rate Conformity (optional)

Informing, during entering a transaction, about the entered price being non-compliant with the current market price or a relevant algorithm.

18. Broker commissions

Configuration of broker commissions according to an algorithm or manually and calculation of broker costs split by transactions and brokers and instrument type

19. Data export/ import

Exporting/importing data from Excel, particularly flows in IRS and CIRS deals

20. Quotes from interbank dealers for sales dealers (optional)

The system should provide for quotes/ streaming of prices (FX spot) and quotes of swap points (for forward deals with clients) from the interbank to sales desk. The sales desk is not able to alter the received quote. Only the interbank dealer may change the quote.

21. Registration of REPO/REV REPO deals

The system should offer the possibility to register REPO/REV REPO deals along with collateral constituted on various debt instruments.

22. Dates Notifying, when entering transactions, on non-compliant dates being entered (value date earlier than transaction date, holidays in various currencies, dates exceeding the limit).

Registering a Counterparty

(Original) registration of counterparties is performed in def3000/TR.The F/O system initiates import of staticdata of counterparties registered in def3000/TR.

of 31

Selected data are required at the counterparty registration level: long name, short name, BIC for banks, Bank’s internal ID (modulo), LEI, counterparty type, settlement accounts, customer’s MIFiD profile, proxy’s name, phone number, password, comment field.

The system should allow deletion (in the form of GDPR-compliant anonymization) of customer data 5 years upon the service is completed by replacing all customer data in the customer file in the F/O system.

Group II – functional requirements for Bank’s liquidity position management

Item Requirement Description of expected system functionality 1. Short-term liquidity

information Presentation of the current forecast of balances, as at day end, of all Nostro accounts split by individual accounts, with a possibility to view all flows on accounts split by the flow types (including flows from Money Market, FX SWAP, FX SPOT transactions, securities, Elixir, SEPA, high amount transactions (Sorbnet2), KDPW (National Securities Depository), transactions with NBP (National Bank of Poland) etc.))

Further, in addition to transaction data, the system is to download external data imported from Def3000/CL (interface described in the integration requirements section.

Possibility to manually enter amounts in the system which are not real transactions (along with subtypes defined by the Bank)

Group III - functional requirements for currency position management

Item Requirement Description of expected system functionality 1. Currencies Parameterization of currencies handled by the Bank.2. Currency position Currency position calculated real-time in the FO system. The position

will be calculated both on the basis of transactions entered directly into the FO by the dealers (interbank, customer, pending transactions) and transactions imported via the interface from Def3000/CP (transaction import described in Section III.4).

Branch transactions concluded after the dealer’s working hours will be entered manually the following morning into the system to balance the currency position displayed in the system from the previous day and Bank’s total position.

FX transactions imported from Def3000/CP should be assigned the reference rate from the current market quote (available via interface between FO and e.g. Refinitiv (Reuters), including the adjustment of this rate by a relevant index/ percentage entered as a parameter in the system.

The currency position will be displayed for specific currencies and groups (e.g. other currencies, all currencies total). The currency position report should be presented as split by currencies and in PLN in order to determine utilisation of limits that may be expressed in PLN and in the foreign currency.

of 31

3. Reporting The system will generate reports on the current currency position, split by currency and limit levels.The system will enable export of results to Excel.

4. Import from Def3000/CP (optional)

The branch position is transferred in real time via an interface from Def3000/CP to F/O. The transfer is conducted automatically within dealer’s working time set in the system parameters.

5. Limits The limit value is set for each position type, split by currency or currency group. The system should handle both the limit set in the currency and as PLN equivalent (PLN is optional).

The currency position, when calculating exposure vs. the limit, is converted into PLN at the fixed rate from the previous day.

The system will enable entering of the following types of limits of open currency positions: limit of Bank’s total open currency position for all currencies in PLN

equivalent (optional) limit of an open position in each currency limit of an open currency position for a given group of currencies

(optional) the system will enable creating new and edit existing currency

groups, which have one common limit (optional)6. Currency position in

a group of currencies (optional)

Based on currency positions in individual currencies, the system will automatically (upon calculating the position in individual currencies) calculate the currency position in the group of currencies for which limits have been defined. The currency position containing more than one currency is set as the higher of two values: the sum of long positions in individual currencies and the sum of short positions in individual currencies.

7. Total currency position in all currencies (optional)

Based on currency positions in all the currencies, the system automatically (after calculating positions in all individual currencies) calculates the currency position in all the currencies total. The currency position is calculated as one of the higher values: the sum of long positions in individual currencies and the sum of short positions in individual currencies.

Group IV – functional requirements for securities position and interest rate management

Item Requirement Description of expected system functionality 1. Collateral

securities Putting selected securities as a pledge (e.g. for lines of financing, REPO, etc.), along with a specific queueing system FIFO or Average Price.

2. Queueing of securities sold

Choosing the manner of selling securities: FIFO, Average Price.

Enable a simulation of P&L changes on a selected portfolio with active queuing of securities

3. Securities operations

Perform operations such as Buy Sell Back, Sell Buy Back, Repo, Reverse Repo (with or without transfer of securities) preserving the selected way of sale (proper queuing of securities sold).

4. Own issues Register and manage the position of Bank’s own issues (including those with the call option).

of 31

5. Valuation of securities

Valuation of securities according to IFRS 9 (e.g. direct market quotes, effective interest method)

6. Effective Interest Method

The system will allow valuation of financial instruments at adjusted buying price.

7. Simulation of portfolio results

Enable simulation of a change of P&L on a selected portfolio/ transactions, preserving the FIFO queuing of securities (considering the existing pledge on securities).

Group V - functional requirements for calculation of FX speculation results (optional)

Item Requirement Description of expected system functionality 1. Calculation of FX P&L Daily results calculatedreal time on transactions according to an

algorithm set by the Bank.

P&L as at day end – generated automatically according to user-set parameters and Bank-set algorithm.

The system will allow calculation of results with reference to: current market rates, today’s referential fixing rate (fixing rate is disclosed after 11.00am every workingday).

2. FX results Drill-down The system should present and calculate results split by: transaction type currency the system will allow isolated calculation of P&L for each

transaction

For positions resulting from transactions concluded on previous days, the drill-down may be limited to the currency.

3. Reporting It will be possible to generate reports of the current FX results, currency position split by the listed items. The system will allow export of report results to Excel.

Group VI – functional requirements for calculation of interest rate P&L (optional)

Item Requirement Description of expected system functionality 1. Presentation of

results Present interest rate results “during the day” and for a given period, split by:

transaction type, including “reference” transactions for securities, split by the instrument’s name categories “during the day” and “as at day-end” at the level of a

single transaction interest income separately for derivatives’ position and debt

instruments’ position day-end P&L – income earned as at day-end

2. Historical data viewing

Available functionality of viewing historical results. The system allows data export to Excel.

of 31

Group VII – functional requirements for customer transaction management

Item Requirement Description of expected system functionality 1. Changes of

transaction periods

Possibility to modify terms of active transactions (particularly shortening and extending derivative transactions) and putting holds on negotiated time deposit funds.

2. Change history Ensured storage of history of transaction changes (e.g. change of notional, interest rate, exchange rate, dates etc.), original transaction data (e.g. in the case of shortening/ extension of derivative transactions)

3. Reporting Report of concluded transactions: modified, cancelled, blocked margins on individual transactions and aggregated lists, including transaction valuation

4. Income from Customer

Income calculation split by: transaction type customer name specific date

Group VIII – Counterparty limit management

Item Requirement Description of expected system functionality 1. Limit types Limit management:

settlement and pre-settlement limits for counterparty (bank, non-bank, issuer, CCP).

global per currency, country, transaction type 2. Dealer’s limit

(optional)Limit assigned to individual dealers for transaction notional per transaction type.

3. Calculation of limit utilisation

Possible definition of the way the limit is utilised: notional value, notional value including risk weight, notional value including risk weight and valuation maximum transaction notional value (not aggregated amount) limit per single transaction establishing limits per groups (i.e. several counterparties utilize one

limit, e.g. per country or financial group) define other rules for limit utilisation according to predefined

algorithms.

4. Division of counterparties

Required separate definition and monitoring of limits split by bank, non-bank, issuer, and CCP counterparties.

5. Limit types It is required to separately define and monitor limits per transaction type (different limits for each counterparty and for each customer).Possibility to set parameters of various limit types due to: transaction type, tenor, currency (e.g. deposit limits, FX derivative transaction limits, IRS limits, etc.) In the case of an interbank counterparty, possibility to define total limits which will sum up utilisation of specific counterparty limits. Possible configuration of limits of non-bank counterparties on an individual basis. As for the issuer limit – utilise the limit by the date of settlement of

of 31

purchase/ sale of securities (before the settlement date, utilisation is assigned to the limit of the counterparty the transaction was concluded with).As for CCP – the limit utilized is the limit of the specific CCP and, if applicable, CCP intermediary (one transaction may be assigned to, depending on CCP, even 2 entities).

6. Individual limits Possibility to set parameters for an individual limit per transaction. It will be functioning as other types of limits (settlement, pre-settlement, issuer limit etc.) but will be assigned to a single transaction (e.g. one limit will be assigned to a single IRS transaction with a customer, who may theoretically have several transactions of this type).

7. Monitoring during the day

When entering a transaction, it is possible to simulate the counterparty limit utilisation. Limit utilisation refreshed on an ongoing basis (along with conclusion of new transactions, modification of existing transactions, transaction cancelling and potential changes of market data).

8. Reports Generate reports of the current utilisation of limits defined in the system, along with the data of limit level, limit effective dates, current utilisation, limit name etc. Each limit type should have a separate report, as different fields will be defined for the reports. The system will enable export of report results to Excel. Limit utilisation will be refreshed in real time, along with concluded transactions and market data changes. When entering transactions, it will be possible to perform simulation of counterparty limit utilisation.

9. Report automation

At a predefined interval, during the day (e.g. every hour) the system will run export of limit utilisation reports – available also on demand.

Additionally, at a specific time, the system will also run report exports (e.g. at day end)

10. Email notification upon exceeding limits (Optional)

Upon exceeding limits, the system sends an email with details to predefined recipients.

11. Non-system transactions (optional)

The system should process additional transactions (without accounting registration) entered to utilize limits. These transactions will utilise both limits related to these transactions and total counterparty limits. The transactions are technical only – they are artificial and do not need to reflect actual transactions. They may have the same type in the system, and be given a name related to their purpose. The dates are to indicate the limit utilisation effective period.

12. Cross Currency Repo (optional)

REPO transactions should have an additional field indicating haircut with which the transaction was secured by securities. The value of bonds securing REPO transactions is nominally higher than REPO transaction amounts converted to PLN. REPO value upon multiplying by haircut (each REPO transaction with even the same counterparty may have a different haircut) should generate

of 31

utilisation of relevant limits.

Group IX - functional requirements for market risk management and monitoring

Item Requirement Requirement description1. Defining VaR

estimation models.

Implemented VaR estimation model (historical). The system should enable editing of VaR model parameters.

2. VaR model assumptions

The Bank provides that the VaR model will have a historical simulation method installed. Model parameters: position maintenance timeframe (e.g. 10 days), which will utilise the

limit significance level method of setting the element/ VaR value at the defined significance

level, through interpolations or downloading a specific value (for e.g. 99th percentile of 250 working days it will not be interpolated but the second biggest change will be taken into account).

length of the timeframe of market data history (interest rates/ exchange rates)

method of calculating changes of market factors (e.g. logarithmic/ arithmetic rates of return)

The model for derivatives will include the dual-curve valuation method (separate projection and discount curves). The system will also offer VaR parametric method.

3. Types of VaR The system will calculate the following VaR types: Interest rate VaR – indicating the maximum loss, at with given

probability, the Bank may incur on open positions sensitive to the interest rate risk,

Currency VaR – indicating the maximum loss, with a given probability, the Bank may incur on open positions sensitive to exchange rate risk,

Total VAR – interest rate VAR and currency VAR jointly Both VaR values should be calculated separately. The system should not calculate the total VAR in any distribution layout or report. Though the document will mention VaR calculation without any split into currency and interest rate VaR, this must be understood as separate calculation of both types of VaR.

4. Division of interest rate VAR

It will be possible to calculate interest rate VAR split by:1) trading book including, additionally, split by transaction types (VAR split by

transaction type should sum up to equal the total trading book value). instrument (for securities, the split into types and per instrument, per

bond name) including the calculated VAR drilled down to the unit value per single

transaction (which is the component of trading book VAR total)2) transaction types in the trading book (VAR calculated separately for

each transaction type – does not sum up to the trading book total from

of 31

item 1) 3) banking book 4) total for interest rate 5) portfolios (internal predefined portfolio names – with names adequate

to IFRS9 (e.g. AFS – – available for sale)For instance, the functionality described above is to provide a possibility to check, whether e.g. within the trading book and calculated VAR, DS0727 charges VAR in the amount of 20000, WZ1122 in the amount of 30000, and IRS derivatives in the amount of 100000, which all reflects the total VAR of the trading book of 150000.

5. Division of currency VAR

It will be possible to calculate currency VAR split by: 1) trading book based on the dealer currency position 2) trading and banking books inclusively, and additionally:- split by currencies constituting the Bank’s currency position of a given day or defined in parameters – both cases are acceptable (VAR split by currency is to sum up to the total trading book)

6. Transaction Types Table

VAR divisions (items 4 and 5) should be set in the parameter table. The table should be editable. The system will enable definition of new transaction types and classifying them into the type of risk, portfolio, trading and bank books. The system will allow classification of transactions into more than one risk type, depending on the VaR model.

7. Continuous calculation of VaR ‘during the day’

The system should, on an ongoing basis, calculate interest rate VAR for the trading book. The other divisions set in item 4 above may be calculated at day-end. Due to the calculation time, continuous VAR may be calculated based on market volatility determined on the basis of the portfolio calculated (and market date) in the previous full VAR calculation process (e.g. EOD process). When calculating VaR, the system should take into account changes resulting from current events ‘during the day’ related to transactions classified into the trading portfolio as: - New transaction - Modification of an existing transaction (affecting VaR)- Cancellation of transaction - Closing of transaction The system should at least once a day calculate the full VAR in all divisions set forth in items 4 and 5.

8. Running extra VaR processing

The system should allow running a complete VAR processing (complete calculation) “on demand”, which will be performed for the current market data, current portfolio and parameters.

9. Calculation of EOD VaR

The system should automatically generate reports of this calculation or offer the possibility to extract data from such calculation at a later time (e.g. next business day) or specify a fixed moment during the day when the data could be extracted. A prerequisite is to be able to extract data/ report on VAR in the requested division layouts from a given day.

10. Splitting EOD VaR by individual instruments/ currencies/ transactions (optional)

In the EOD process, the system – according to divisions described in items 4 and 5, should be able to provide the drill-down of the calculation, depending on the division. For bonds, the system should offer the possibility to view VAR split by bond name. For currency VAR, by a single currency and for IRS derivative transactions, by a single transaction.

of 31

11. Entering VaR limits

The system should offer the possibility to enter and set parameters of limits for VaR ‘during the day’ for the trading book.

12. Entering EOD VaR limits (optional)

The system should offer the possibility to enter and set parameters of EOD VaR limits for the trading book.

13. Simulation of limit utilisation

The system will allow manual entry of a hypothetical transaction for which it will calculate VaR (simulated transactions). The system should allow entry of more than one hypothetical transaction. The system will set VaR for: a portfolio of transactions entered only manually, a portfolio of consisting of the current positions and additional

positions entered manually. These VaR values will be displayed on the desktop only for the user who entered the simulated transaction. The process of current (or full) processing of VaR should not include the hypothetical transaction. The system will indicate whether after potential conclusion of the contract, the VaR limit for a given type would be exceeded.

14. Holidays When calculating VaR the system will skip bank holidays when calculating exchange rate/ interest rate changes.

15. Exceeding of limit The system will automatically notify of exceeding the limit during the day. 16. Email notification

upon exceeding limits (Optional)

The system will send an email notification to predefined recipients once any limit is exceeded. The email should contain a relevant report (e.g. VAR versus the limit, limit name etc.)

17. VAR backtesting (optional)

The system will allow backtesting of VaR model. The system will run two types of backtesting: historical and revaluation. For historical backtesting, the system will use EOD VaR values calculated for the last x business days (x – backtesting timeframe as a system parameter, 250 business days by default). 1-day EOD VaR is compared with revaluation results on original positions, results subject to the irregular value model, arising from actual changes of price parameters, calculated with an assumption of a fixed value for 24 hours and original position structure. For the purpose of revaluation backtesting, the system will use EOD VaR calculated for the last x business day (backtesting timeframe as a system parameter, 250 business days by default). 1-day EOD VaR is compared with the speculation result of the following day (respectively, specified in the bullet above), without taking into account transactions concluded on the day for which the result is set. The system presents the historical and revaluation backtesting results on a chart: separately for interest rate VaR and for currency VaR. The chart presents the period x business days (backtesting period set as a system parameter) from a selected report date. The chart presents VaR on a given day and the value of comparable speculative result. The system indicates the number of VaR exceeding events – number of events when the loss on trading operations was higher than VaR. VaR exceeding events are displayed in the chart in a colour different from the values not exceeding VaR. The system will enable export of the backtest chart to Excel. The system will allow extracting the data used for drawing the chart.

18. VAR Stress Tests The system allows performing on-demand stress tests of VaR according

of 31

(optional) to scenarios prepared as part of the method reviews. Stress tests should be run based on EOD data. Stress test scenarios should take into account disturbance of: price parameters, correlations of price parameter changes, volatility of price parameters, market liquidity level, structure and values of bank’s original positions. The system will allow viewing of stress test results and exporting them to Excel. The system will enable the user to define/ modify scenario parameters.

19. BPV The system should calculate BPV on an ongoing basis and at day-end for all the transactions sensitive to the interest rate risk in the trading book. The parameters determining which transactions are classified into the trading book will be the same as those for VaR. Current calculation may be based on the previous day’s curves. EOD calculation should be based on current curves – fed prior to the end of day. When calculating BPV the system should take into account the current (during the day) changes to the transaction portfolio (new transactions, changes to existing transactions, transaction cancellation, transaction closing).

20. BPV Stress Tests (optional)

The system allows the user to define/ modify scenario parameters. The system allows viewing of stress test results on the desktop and exporting them to Excel. Stress test scenarios should take into account disturbance of: price parameters, correlations of price parameter changes, volatility of price parameters, market liquidity level, structure and values of bank’s original positions.

21. Calculation of total EOD BPV

The system should automatically generate reports of this calculation or offer the possibility to extract data from such calculation at a later time (e.g. next business day) or specify a fixed moment during the day when the data could be extracted. A prerequisite is to be able to extract data/ report on VAR in the requested division layouts: tenors, transaction types, currency, projection curves, discount curves.

22. Entering BPV limits

BPV limit ‘during the day’ is entered into the system as a parameter. Defined limits: - limit of open BPV position split by transaction type (BPV calculated

separately for each tenor and transaction type – the sum of these calculations is subject to verification against the limit)

- limit of open total BPV position (BPV calculated separately for each tenor and transaction type – the sum of these calculations is subject to verification against the limit)

23. Entering EOD BPV limits (optional)

The system should offer the possibility to enter and set parameters of limits for EOD BPV for the trading book.

24. Divisions of calculated BPV

The system should calculate BPV simultaneously in the splits specified below (to obtain, for instance, BPV for bonds, 3M tenor in PLN for an XYZ curve):- Currency- Transaction type - Interest rate curve tenor: ON, TN, SW, 1M, 3M, 6M, 1Y, 2Y, 3Y, 4Y, 5Y,

6Y, 7Y, 8Y, 9Y, 10Y, 15Y – when interest rate curve tenor changes, the system will calculate BPV for all the tenors of the new curve.

of 31

- Discount curve type - Projection curve type

25. Selective calculation of BPV

The system should enable the user to calculate, on demand, for a given moment, BPV for a single transaction/ several transactions/ selected in all the IR transactions available in the system (also those not classifying for speculation). The system will enable export of calculation results to Excel (according to the required BPV divisions).

26. Calculation of BPV for a hypothetical transaction

The system should allow entry of a hypothetical transaction (transaction data required for BPV calculation) and on user’s demand will calculate the transaction’s BPV. The system indicates utilisation of the BPV limit after potential conclusion of the transaction and whether the limit (for the current portfolio and new transaction) is preserved or exceeded. The system will enable export of calculation results to Excel (according to the required BPV divisions).

27. Running extra BPV processing

The system should allow running a full BPV processing (complete calculation) on demand, for the current market data, current portfolio and parameters.

28. Setting internal limits (optional)

The system will enable setting an internal warning limit for coming close to exceeding the limit for the currency position, counterparty position.

29. Exceeding of limit The system will automatically notify of exceeding the limit during the day. 30. Email notification

of exceeding BPV (optional)

The system will send an email notification to predefined recipients once any limit is exceeded. The email should contain a relevant report (e.g. BPV split by relevant items versus the limit, limit name etc.)The template of the limit exceeding notification email should provide for parameters/ be editable.

Group X - functional requirements for regulatory reporting

Reporting transactions according to statutory requirements

1. Providing data for APA reporting for export

Providing transaction data required by MIFID II for export from the system for the purpose of APA reporting: (ISIN, instrument type, asset class, asset sub class, quantity, quantity type, notional, notional currency, execution time, submission time, venue of execution, price, price notation, trade date, direction, report type, initial deferral flags, submitting party trade capacity, counterparty trade capacity, deferral flags, ISIN, submitting party LEI, reporting party LEI, counter party LEI and others)

2. APA reporting (optional)

Automatic reporting of transactions to APA (reporting according to legal regulations, MIFID II observing the report due date requirement). Archiving of report evidence, tied to the original transaction, with a possibility to generate reports in the system. Fields required for APA reporting: (ISIN, instrument type, asset class, asset sub class, quantity, quantity type, notional, notional currency, execution time, submission time, venue of execution, price, price notation, trade date, direction, report type, initial deferral flags, submitting party trade capacity, counterparty trade capacity, deferral flags, ISIN, submitting party LEI, reporting party LEI, counter party LEI and others)

3. Sending data to Backoffice system

Fields to be interfaced: UTI, trading venue, hour, minute, second, millisecond of transaction conclusion, ISIN SPOT, ISIN FORWARD, OTC post-

of 31

(Def3000/TR) via interface for ARM and EMIR reporting

transaction indicator, ID in the trading system, reference rate, margin, short selling indicator.

Group XI – additional requirements for system operations

Item Requirement Requirement description1. Feeding market

data and curves From a specific location the system will download current curves for valuation of financial instruments. Additionally, from this location, the system will download market quotes for securities. It will also be possible to download other market data (e.g. fixed rates).

The location will also contain excel files in a relevant format. Each time the file is made available, the data should be uploaded and treated as current.

2. Curve creation (optional)

The system should provide its own mechanism for drawing curves of interest rates used for the market pricing of financial instruments. Whether the Bank will use the curves fed by the Excel files mentioned in XI.1 or use its own mechanisms should be available for parametrization.

For each curve the system should have the possibility to indicate whether it is created using market data and FO system or whether it is fed by an outside source (item XI.1).

3. Connection with market data system Reuters/Bloomberg

The system will be connected with a market data system from Refinitiv (Reuters) or Bloomberg (the vendor will be selected by the Bank).

4. Transaction valuation

The system will handle the following valuations: - market valuation arising from instrument price (e.g. debt instrument)- market valuation calculated from the curve (e.g. FX SWAP, FX FORWARD)- market valuation using two curves – one for projecting interest rates and the other for discounting of cashflows, so-called dual-curve (e.g. IRS)- linear valuation- valuation with effective interest method of amortization

5. P&L split Calculated P&L split by realized and unrealized

6. Result cut-off at end of period

The system enables cutoff of the result (e.g. at end of day, month, year). From the cut-off the result is calculated from the beginning.

7. Cost of Carry Cost of carry should be calculated separately for positions for derivatives and separately for debt instruments.

In the starting list, the cost of carry would be Polonia market rate (O/N rate).

8. Realized interest income

The system should report the realized interest income split by individual instrument groups.

of 31

9. Downloading data from system database

The system should enable, without any (licence or technical) obstacles, downloading data directly from the system database (such as transaction, limit, current positions, limit exposures, VAR, BPV data etc.).

In this respect (data entered into the system and calculated as presented in the requirements herein), the system should provide for unrestricted use of data.

10. Exporting data to data warehouse

The system should enable exporting data to a data warehouse at day-end (just like the data specified in XI.5)

11. Reset of reference rates

The system will automatically set a new reference rate (LIBOR,EURIBOR etc.) for a transaction that will require reset. The system will also provide for manual modification of this rate.

Group XII - Autodealing (optional)

Item

Requirement Description of expected system functionality

1. Access to application Ensuring functionality of one-off log-in, i.e. the client runs the autodealing application from internet banking system level

2. General parameterization

Email addresses of Bank employees, to which the following will be sent:

o Notification of defining a new client o transaction execution confirmation o pop-up window for the client confirming contract

conclusion Start and end times for transaction execution – transactions

beyond these hours will be executed on client’s terms as the first ones the following day

Types of concluded transactions, e.g. FX SPOT, FX ORDER

Currency pairs within which the above transactions may be concluded

Minimum amount for a given transaction type and a given currency pair

Time for client’s decision on whether to conclude the transaction

Margins – margin parameters concerning: o Value of concluded transaction – for automatic

quotes. o Transactions above predefined limits are always

quoted by the dealer o A single client or a group of clients

3. Client parameterization The application should offer parameterization of:

Email addresses to which transaction conclusion confirmation will be sent

Types of transactions provided to the client Currency pairs – if limitations are applied to general

defined currencies for transactions Accounts used for concluding transactions

4. Calendar The application should maintain a calendar including bank

of 31

holidays 5. Currency exchange

rates Presentation of current exchange rates for

currency pairs provided to the client, with a clearly marked currency pair, e.g. EUR/PLN. An increase of the presented exchange rate should be marked green, while the decrease – red.

The presented exchange rates should be refreshed at a frequency of at least 2 seconds – fed from the outside from xls, html, or other files or via a web service.

6. Charts Presentation of charts selected by the client. The client

should be able to choose a chart by selecting:

the currency pair the chart type (candlestick charts or line graphs) the range of presented data (max. up to 2 years), intervals (continuous, 5min, 15min, 1h, daily,

weekly)

7. Available funds Presenting to the client the balance of funds available for

transactions:

Funds on defined accounts Available limit for concluding transactions with future

dates 8. Concluding FX Spot

transactions Possibility to conclude transactions from the exchange

rates tab After selecting the transaction type (Buy or Sell) the

system automatically suggests predefined accounts in relevant currencies

The amount (to be filled out automatically, depending on the selected transaction side on a given pair) should be modifiable (increased, decreased)

Settlement date (possibility to enter a date or select it from the calendar) in the case of tomorrow or spot date, necessary to have a limit; if a bank holiday date is selected, the system should display an error message such as “Incorrect date”.

Bar showing remaining time for the decision set by the Bank for transaction conclusion, client’s acceptance of the transaction. Once the time

of 31

lapses, the exchange rate is no longer valid) Information on the minimum amount which allows

for sending an exchange rate query to the dealer. Communication with the client (chat) – the dealer

and the client may exchange messages when concluding the transaction. The chat conversation becomes active when the client sends an enquiry about the exchange rate to the dealer and ceases to be active when the client rejects or accepts the offer.

Buttons for accepting transaction terms, for cancellation and for sending exchange rate enquiries to the dealer. The “send enquiry to the dealer” should be active when the client meets minimum requirements for negotiating with the dealer.

After concluding a transaction, the system displays notification “Transaction concluded. Find confirmation in the list of transactions”.

When there are no funds for concluding a transaction or no available security for the transaction, the system should display relevant notifications to the client, e.g. no funds available/ no available security for the transaction

e-mail to the client to confirm transaction conclusion, if the client provides an email address and defines it in the system.

9. Transaction history possibility to select the range of data of the presented history (dates from-to) – selecting a calendar or entering dates into dedicated fields),

searching for transactions by ID, selecting range of dates for the presented data, selecting range of amounts of the presented date, selecting transaction type (spot, order), selecting transaction status (pending, executed,

settled) selecting currency pair, history should cover data from the first transaction

concluded on the FX platform from the history level, the client should be able to

generate a PDF confirmation for a given transaction real-time refreshing of history of concluded

transactions downloading transaction confirmation directly from the

history

10. Dealer panel The dealer panel should provide for:

of 31

browsing the client database, generating reports, browsing the margin matrix of a given client, receiving exchange rate enquiries, communicating with the client when negotiating

transaction terms, switching off client’s automatic conclusion of FX

transactions on the platform.

11. Reports available from dealer level

Report of all concluded transactions Client activity report Report presenting groups of clients Report (daily event log)

12. Messages Application should present messages sent by the dealer. 13. Integration with other

systems Receiving information on current balances on

client accounts. Checking sufficient funds and putting holds on

funds on the sold currency account in the core system – for transactions concluded for amounts up to all funds on the account

Updating the limit in the core system – for transactions concluded for future dates

Online transfer of concluded transactions to the core system

The platform should be fed spot rates with the use of files generated by the Bank

Autodealing transactions are booked online to Bank’s FX position.

B. INTEGRATION REQUIREMENTS

Item Requirement Requirement description

of 31

1. def3000/TR Two-way interface with Def3000/TR back-office system, providing, among others: a) Transaction data transmission:

new transactions, editing of concluded transactions (e.g. shortening, extension,

etc.) cancellation

b) Transmission of static counterparty data from def3000 TR to the F/O system: short name, long name, BIC SSI (standard settlement instructions) list of available settlement accounts identification password, list of proxies, phone numbers, ID of concluded contract, LEI.

2. def3000/CL Interface from def3000CL to the F/O system providing transfers of high amount customer orders in PLN (SORBNET2 – Polish clearing system) and customer orders in foreign currencies (status executed). Applies to all orders beyond Elixir and EuroElixir (Poland’s clearing systems).

3. def3000/CP Interface downloading information from a system calculating Bank’s currency position. The F/O system will extract from this system data of the currency position from transactions concluded outside the F/O system (branch position).

4. def3000/CB (optional) Interface from/to def3000/CB for the needs of the "autodealing" functionality in terms of downloading the current customer’s balance and blocking funds on the customer's account up to the amount of the trade and on-line booking of transactions done.

5. Reuters FXTrading (Refinitiv)

Transaction import

6. Reuters Eikon (Refinitiv)

Online interface to download current market data.

7. Bloomberg Transaction import.8. Bloomberg Online interface to download current market data.9. Markitwire Transaction import 10. FXALL, Goldman

Sachs, Barclays, BNP, DB- Autobahn, CitiVelocity, Credit Agricole, Societe Generale, Deutsche Autobahn

Transaction import

11. APA Data export

of 31

12. Data warehouse Exporting data from the F/O system to Bank’s data warehouse at day-end, comprising, among others: currency position, interest rate position, VAR, BPV, exposures vs. limits (all data of limits and exposures), counterparties and parameters, transactions, valuations. The detailed list of data items will be agreed upon with the provider, depending on the proposed implementation scope.

of 31

C. TECHNICAL AND TECHNOLOGICAL REQUIREMENTS C.1. Building Front Office System (“the System”)

1. The System should be based on reliable and efficient technological solutions, ensuring high efficiency, data security and ability to integrate with other systems. The System should offer extension possibilities and provide for adding new business modules and functionalities to address legislative changes regarding System operations or functionality. A business administrator should be able to parameterize the System. As for development, the System should offer tools for design/ definition/ modification of:

a) user roles, b) calendars and schedules (reminders, lists of to-do tasks;c) templates of documents and messages complying with business rules; d) reports, analyses.

2. A functionality is required to allow for user and rights management, which should enable control of authorisations to access the System and System elements.

3. The system should allow Bank employees to work on their own, without any involvement of consultants of the Bidder or other third parties, also when changing components, processes, etc.

C.2. Architecture and technology requirements 1. The System should have a 3-tier technology (BackOffice user interface, business logic, data layer).2. The System should communicate with other applications, at least via WebServices, ESB and others,

such as API.3. The System should run on AIX 7.2, MS Windows Server 2016/2019, Red Hat Linux 8.x (preferred).

Other Linux systems are also acceptable Linux, e.g. CentOS, on condition service support is provided. 4. The database server should use Oracle 19c, MS SQL 2016/2017, IBM DB2 and newer technologies

(preferred). Acceptable are also offers based on other systems, such as PostgreSQL, MySQL, on condition service support is provided.

5. If the System uses a web server, it should use WebSphere 8.5.5/9.0, Weblogic 12.2.x, JBoss 7.x EAP and newer technologies (preferred). Acceptable are also other application servers such as WildFly, Tomcat, on condition service support is provided.

6. The System should allow user authentication based on Bank’s Active Directory solution.7. The System should process all kinds of enquiries, calculations, computations etc. on the server side.

The user workstations should present only the outcome of these operations. 8. If the System uses a web server, it should provide the user interface via a web browser (Internet

Explorer 11 and higher, MS Edge, Mozilla Firefox 46 and higher, Google Chrome, using a secure data exchange protocol with HTML at least ver. 5 and CSS at least ver. 3).

9. Sizes of applets, libraries, and other application components essential for proper operations, downloaded to the user workstation, should not exceed 500kB.

10.The offer should contain descriptions of implementable Disaster Recovery solutions, taking into account:

a) integration with the central backup system - Symantec Netbackup 7.7.3 and higher,b) redundancy of hardware infrastructure, telecom connections to the primary and backup data

centres,c) use of active-active cluster solutions.

11. The System should allow integration with archiving system Vault 12 and higher.12. The System should be available in the 24/7/365 mode. The system should be based on high-availability

architecture. 13. The system will use Bank’s primary and secondary data centres.

of 31

14. The System will allow for using Bank’s existing network infrastructure (e.g. firewall, switches, load balancers) and hardware infrastructure (virtualization platforms, e.g. VMware, IBM PowerVM,). The offered infrastructure should meet the System’s performance, technical and organisational requirements specified herein, but the technical architecture should, in particular, specify network protocols and data exchange methods, both between individual modules of the System and between the System and external applications, systems, databases.

15. The Bidder must present the technical architecture of the proposed solution specifying: a) the servers, b) telecom lines, c) other devices required for the System operations, d) disk space utilisation within 1-, 2-, 5-year timeframes, e) licence requirements.

16. The Provider will offer such technical infrastructure parameters for the offered system that will ensure optimal operations of the production (including the failover instance), test and development environment.

17. The Provider will specify database and system software necessary for system operations. 18. In his offer, the Provider will present an analysis of network traffic generated by the offered system

(from and to the user), which will be subject to verification by the Bank during the project implementation period.

19. The provided system will be internally tested by the Provider prior to the delivery to the Bank. 20. The System must provide for change management in the processes through: a test version in the

Provider’s environment, migration of test processes to the test environment, migration of test processes from the test environment to the production environment at a specific date. Process versions must be migrated between Bank environments without the involvement of the System Provider – as an administrative function.

21. Error messages or messages informing about incorrect operations of the System should be presented in Polish or English, but as for messages recorded in application logs, parameters should allow for granular levels of event logging. The System must enable run in full screen at the minimum resolution of 1024x768 and automatically scale to the hardware resolution.

22. Operating the System should be possible with the use of mouse and keyboard. 23. A technical administrator should be able to configure the System’s technical aspects – this applies, in

particular, to the main catalogue of applications, paths, disks, www addresses, port numbers and database names.

24. The System should be able to run correctly in a network environment, taking into account the following factors, involving both the System’s communication with external applications and communication between its own components: a) limited bandwidth, including bandwidth limited by packet loss filters, packet losses;b) connection termination; c) large network workload.

25. Communication with other systems: a) The system should provide for a possibility of exchanging data also using export/ import of files, at

least in the XML/CSV format – for the purpose of exchanging data sets (e.g. data export from warehouse) or directly from Oracle, MS SQL databases.

b) SQL queries; the system should allow data downloads using direct online from the System database. c) The System should allow logging entries to SIEM systems. d) The System should be based on the System Oriented Architecture (SOA); the System should provide

network services, which may be directly used by the Bank system. The System will communicate with Bank systems, which will be defined by at the project analysis phase.

C.3. Performance requirements

of 31

1. The solution should ensure the possibility to build efficiency and reliability clusters. 2. Scalability of the solution should ensure correct operation of the System for a predictable number of

users and anticipated volumes of processed data as well as the possibility to scale the System infrastructure along with its development (scalability without having to upgrade the system).

3. As for the reliability of the solution, the System should offer automatic (for instance, as a result of a failure of the primary instance) and manual migration to another server, with a loss-free migration of data critical for system operations (transaction logs, queued messages, statistics, logs, etc.). This functionality should run independently of protocols of the transport layer. The solution should offer failover mechanisms allowing for switching over to a backup instance as a result of a failure.

4. The system should offer the possibility of database partitioning to ensure higher efficiency of processing current data, while ensuring access to the archived data, for instance, split by past years (this requirement is optional – if the offered system does not provide for database partitioning, it is required to present technical solutions in place which ensure the same performance when processing the growing data volumes).

C.4. Requirements for the System’s controls and technical conditions for the System security.1. The System should ensure the following controls: audit trail.2. The audit mechanism should monitor the operator or administrator activity regarding archiving,

cleaning, configuration changes and other major operations – full configurable audit.3. The System should have an audit trail demonstrating whether there have been unauthorised attempts

to access the System or application. 4. The System should have a log management module to record log-in, log-out events with dates, times,

user IDs and computer IDs which logged in or logged out. 5. Name, location and rotation of log files and the level of logging should be configurable, particularly the

log rotation mechanism should offer the possibility of setting the log rotation interval to daily, also upon exceeding the predefined log size limit, while the rotation process itself should not require or result in application termination, and the old log should not be overwritten with a new one.

6. There should be a possibility to monitor data processing. 7. The System should offer the option of monitoring all activity of users and/ or administrators (privileged

users).8. The System should ensure data security in compliance with the Polish and EU legal regulations and fulfil

reliability requirements and offer the following functionalities: a) access to data, operations and products should be limited to users assigned specific roles in the

System; b) assigning, removal and change of authorisation to a specific role; c) backup; d) support for encrypting user interface communication with the System or System communication

with other applications (internal and external);e) setting and verification of acceptable password strength; f) configuration of password validity periods, forcing password changes at predefined intervals; g) storage of only encrypted passwords in the System – the passwords should not be displayed at any

time when entering; h) monitoring and reporting of failed System/ application access attempts; i) maintaining integrity of data exchanged with other applications and systems; j) maintaining data integrity upon disaster recovery;

of 31

k) a mechanism ensuring all operational elements are processed fully and completely; l) easy use, configuration and administration; m) guaranteed execution of rights of people whose data is processed in the System as required by

GDPR; n) functionality to delete/ anonymize personal data upon data retention periods, o) storing personal data in encrypted forms.

9. The Bidder should ensure the possibility and method of removing critical System errors and implementing solutions to those errors.

10. The System should fulfil the following configuration and administration requirements: a) The System should have a graphical administration console, offering full possibilities of visual

configuration, monitoring and managing System operations and services; web browser access is the recommended mode;

b) it is also desired to have other methods of configuration, monitoring and management, including, in particular, possibility to run configuration scripts;

c) the architecture solution should ensure the possibility of easy configuration between various environments (e.g. development, test and production environments); the system should ensure control of integrity of the propagated configuration and validation;

d) The System should have failure-free default settings – a standard reaction to each incorrect activity should be refusal to execute the request; as a result, if the user request results in refusal, the System remains secure.

C.5. Training requirements 1. The Offer should comprise training for:

a) System Users/ Business Administrators (min. 2 training days = 16 h),b) System Administrators and Managers – IT (min. 2 training days = 16 h).

2. Each training session should end in an examination verifying the learning of the presented material. 3. The Bank may request additional training as it deems required. 4. For the additional training programs, the Contractor, in the attachment presenting remuneration,

should include manday rates for preparing and conducting additional training. 5. The training will be held at the site provided by the Client. 6. The Bank will determine the number of training participants.

of 31

C.6. System documentation requirements 1. Documentation enclosed with the System should include:

a) post-implementation documentation: installation and implementation specification, description of the System architecture, along with implementation schedule graph presenting

the placement of physical system elements (artefacts) and physical system hubs components, development solutions in place, interfaces with other systems, computation methods in place, including detailed descriptions thereof, description of security aspects implemented in the application.

b) specification of use: user documentation:

o complete set of information required for all System business and operational groups, o description of database tables, including parameter tables.

administrator documentation:o System user management rules, o description of operational procedures, o description of administration procedures, o description of installation procedures, o description of System environment, o description of organisation procedures, o description of System security procedures (backup), including description of

Backup/Recovery (BR) and Disaster Recovery (DR) procedures, o description of the database structure, o interface documentation, o personal data management rules (including, in particular, anonymization,

pseudonymization processes, the right to be forgotten).c) documentation of data model, database structure, including in particular the method and place of

storing personal data within the model.

2. Post-implementation documentation should fulfil the following requirements, in particular: a) specify the mode of installation, assuming that the application operates in compliance with the rights

of the dedicated user having the lowest possible authorisation assigned; it is necessary to specify all the required rights to read/save, both for the system file and databases;

b) specify all network access rights required for correct operations of the product, even if the components operate within a standalone machine; the required information comprises: protocol, ports (for TCP, UDP), information about the source and destination of communication (e.g. for IP), information about the direction of the established session (e.g. TCP) or description of the communication scheme (e.g. UDP); for a multi-component application with TCP/UDP/IP-based communication, individual components must be deployed on different machines;

c) specify all the required system components and file resources necessary for correct application operations; this applies also to all external subsystems (e.g. mail server for the mail application) and libraries (e.g. ssl for applications using encryption);

d) specify the installation method, assuming physical separation of all the components (for applications with TCP/UDP/IP-based communication); this means that the installation instruction should take into account that each of the components of the full installation: application server, database and other components will run on different, dedicated physical machines;

e) specify procedures for implementing, termination and upgrades of software;

of 31

f) inform about the scopes of essential backups in order to be able to recover a working application, assuming only the backup copy and the installation files are needed; this, in particular, applies to configuration files and other elements essential for correct operations;

g) specify procedures to optimise and re-index (if needed) databases by indicating which elements of the databases may be deleted (archived) and which ones may be re-indexed and specify the prerequisites for re-indexation;

h) inform about necessary periodic tasks to be performed to ensure appropriate operations of the software and the database;

i) inform about necessary administration procedures for individual System modules; j) specify monitoring procedures (error detection methods, classification of issues, notification

methods) and specify which information should be recorded in system logs; k) specify the mode of operation upon failures of individual System modules (e.g. database, application

server); l) specify all configurable technical variables and allow parameterization thereof (application’s root

directory, paths, disks, web addresses, port numbers, database name); m) not contain installation options for redundant/ unneeded software (e.g. Java SDK if only JRE is

sufficient, etc.);n) contain a description of configuration of logging in; o) the documentation should be drawn in the Polish language.

3. The documentation should provide for an option to take over System maintenance by Bank’s own employees or an entity outsourced by the Bank.

4. Subsequent versions of the documentation should be properly marked and contain a change tracking table (date of entry, authors and approvers).

C.7. Service and maintenance requirements The Bank expects the Bidder to provide the following maintenance services: correction of software errors, installation and parameterization of new, tested software versions and assistance in installation those

versions, provide consultancy and support in justified cases.

The maintenance agreement should contain controls of submitted service tickets, which will allow the Bank to properly supervise the performance of corrective actions.

In the Offer, please, prepare terms of the offered support, along with potential costs of further development of the System upon Bank’s request.

of 31

D. IMPLEMENTATION REQUIREMENTS

Taking into account the Bidders’ experience in implementing system solutions for other clients, we hereby request that implementation project recommendations be presented. We expect the Bidders to present a proposal of the implementation schedule, in accordance with best project practices. We expect the Bidders to specify the funds and human resources essential for completing the implementation and specify the Bank’s resources in this respect. In particular, you are requested to specify:

1. a proposal of the implementation schedule, including: a) the list of tasks, scope of works, indicating the party responsible for performing individual tasks and

works, b) the planned stages, including estimated due dates for starting and completing the works, c) key implementation team members and their experience in implementing Systems for other banks in

Poland and the EU and their planned involvement in the project, d) the proposed plan of BOŚ S.A. personnel’s involvement (skills, effort, etc.),e) the list of project products, correlated with the project schedule, including relevant descriptions

thereof. 2. The Agreement will be concluded in accordance with the Polish law, in Polish as the prevailing language. 3. The name, address and country of domicile of the entity with which BOŚ S.A. will potentially conclude the

Implementation Agreement.4. Present a brief agenda of workshops/ training sessions for the Systems, for which the Bidder offers

implementation services.

of 31

zapytanie ofertowe · web viewcashflow report for treasury deals split by currency, individual...

Documents