Sm44 Books Records

Page no: SM44

 

1       Document Overview… 6

1.1        Purpose and Scope of Document. 6

1.2        Intended Audience. 6

1.3        Settlements Business Subsystem.. 6

1.4        Acronyms and Abbreviations. 6

2       Overview of the Books & Records Business Subsystem… 8

2.1        Overview.. 8

2.2        Business Information Entities. 8

2.3        Business Components. 9

2.4        Data Stores. 9

3       Business Information Entities. 10

3.1        Settlement Obligation. 10

3.1.1         Settlement Obligation of type Booking. 10

3.1.2         Settlement Obligation of type Delivery. 10

3.1.3         Settlement Obligation content 10

3.2        Cash Control Equation (CCE) 11

4       Different Business Models. 12

4.1        Introduction. 12

4.2        Broker Dealer. 12

4.3        Core Custody. 12

4.4        Extended Custody. 13

4.5        Prime Brokerage or Prime Services. 13

4.6        Private Banking. 13

4.7        Summary. 14

5       Position keeping methodology in the TIM… 15

5.1        Key concepts. 15

5.2        Scope: Which positions “owners”. 15

5.3        Scope: Which “kind” of positions. 15

5.4        Scope: Which kind of dimensions. 15

5.5        Business Processes. 16

5.5.1         Ownership. 16

5.5.2         Other purposes. 16

5.6        Booking Processes. 16

5.6.1         Introduction. 16

5.6.2         Internal booking. 16

5.6.3         Expected booking. 16

5.6.4         Actual booking. 16

5.6.5         Challenges for booking actual 16

5.7        Out of Scope. 17

6       Business Components. 18

6.1        SOH as mediator and Operations’ entry point. 18

6.1.1         Interaction Steps. 18

6.1.2         Component Inputs and Outputs. 19

6.2        Settlement Obligation Handler. 21

6.2.1         SOID Creation, Assignment and Version Management 21

6.2.2         Amendments and Terminations. 21

6.2.3         Validation and Checking. 22

6.2.4         Routing SOs and FFs. 22

6.2.5         Functional decomposition. 22

6.3        SF Settlement Feeder. 24

6.4        CR Cash Record. 24

6.5        SR Stock Record. 26

6.6        Suspense Account Handler. 26

6.7        Interest Calculation. 27

6.8        Availability Check. 27

6.8.1         Availability check. 27

6.8.2         Liquidity check. 27

6.8.3         Different kind of checks. 27

6.8.4         With or without reservation. 27

6.8.5         With or without a token. 27

6.8.6         Over several systems. 28

6.8.7         Difference cash and securities / Fongibility. 28

6.8.8         Cash and currencies. 28

6.8.9         The reservation system.. 28

6.8.10      Time point of check and consequences. 28

6.8.11      Availability and Liquidity checks in TIM 2.2. 28

6.9        Shareholder Registry. 29

6.10     Cash Account Statement. 29

6.11     Securities Account Statement. 29

6.12     Bank Notes Inventory. 29

6.13     Functionalities not placed in the B&R components yet. 29

6.14     XXX. 30

6.15     XXX. 30

7       Data Stores. 31

7.1        Settlement Obligation Store. 31

7.1.1         Summary. 31

7.1.2         Business entities maintained. 31

7.1.3         Description. 31

7.2        Cash Record. 37

7.2.1         Description. 37

7.2.2         Business entities maintained. 38

7.3        Stock Record. 38

7.3.1         Description. 38

7.3.2         Business entities maintained. 39

7.3.3         Active vs. passive stock record. 39

8       Position Keeping.. 40

8.1        High level BOM and considerations for securities’ position keeping. 40

8.2        Key concepts of position keeping in the TIM… 41

8.2.1         Position separating attributes or position building attributes. 41

8.2.2         Required Position (balance quantity) views. 42

8.2.3         Position Keeping principles, capabilities and scope. 43

8.2.4         Blocking concept 44

9       Booking date challenge. 45

10         TIM Conformance. 46

 

1         Document Overview

1.1      Purpose and Scope of Document

The primary goals of this document are to provide:

• a high level description of the Books & Records Subsystem in context of the overall Operations Processing Business System including the business components, functions, inbound and outbound flows and stores
• a description of how the Books & Records Subsystem conforms to the Target IT Model (TIM) end-to-end design principles

Out of scope of this document are:

• The internal details on TIM business subsystems other than the Books & Records Subsystem
• The detailed Sparx EA models – these will be documented in the Information and Lifecycle Document and the Component Interaction Model

1.2      Intended Audience

This document is intended for Ops and Ops IT. It is assumed that all recipients have an understanding of Operations services.

1.3      Settlements Business Subsystem

This document should be read together with the Settlements Business Subsystem Overview document as many of the interactions and business entities are shared across the two subsystems. In particular, Fulfilments and Settlement Instructions entities are fully covered in the Settlements Subsystem Overview and so are referenced but not fully defined here.

Additionally, the summary interactions in this document cover end-to-end processes across Books & Records and Settlements.

1.4      Acronyms and Abbreviations

This section provides a list of acronyms used in this document. Glossary of terms can be found in << link>>

 

2         Overview of the Books & Records Business Subsystem

2.1      Overview

Books and Records business subsystems comprise business components around shared position and settlement obligations’ data stores. Collectively, they ensure integrity between the internal and external view of balances and open Settlement Obligations. The data stores are intentionally separated from the systems which populate them and those which use the data, in order to support the shared data principle that guides our designs.

Figure 1 – The Books & Records Business Subsystem

2.2      Business Information Entities

• Settlement Obligation (SO) – this represents a contractual obligation created by both Trade and Non-Trade activities. It is produced pre-settlement, where CS is the instigator, and it reflects what is expected to settle, how, when and with whom. SOs are generally internally generated, with the exception of where power of attorney (PoA) has been given to 3rd parties to create such items on behalf of CS. There are two types of Settlement Obligation:
• Settlement Obligation of type Booking (SO(B)) – if the accounts involved are serviced entirely by CS within a single legal entity, it is deemed an internal settlement of type Booking (SO(B)). SOs of type Booking do not involve external settlement, so are immediately actioned on the settlement date.
• Settlement Obligation of type Delivery (SO(D)) – if at least one of the accounts involved is serviced externally or the accounts belong to different legal entities, it is deemed an external settlement of type Delivery (SO(D)).

An SO has one or more ‘legs’ categorized as cash, fees or securities.

• Fulfilment (FF) – this represents a matched advice or confirmation received from the market and  where CS is the recipient, and reflects the actual situation. In other words, the FF represents the post settlement situation reported by the market in the form of advices and confirmations

In summary:

• an SO(D) represents an ‘expected view’, i.e. the internal view of expected obligations and how and when they will be received.
• the corresponding ‘actual view’ is booked when the SO is matched with – one or more  – FF.
• an SO(B) represents both the ‘expected and actual view’, i.e. the actual internal obligations which will be internally transferred.
• Inter-entity bookings will force the SO generator to create one SOM per involved legal entity. It is primordial that these SOMs are linked.
  • Settlement Obligation Handler (SOH) – this provides a mediator between trade management processes such as capture, allocation, novation and confirmation and Settlement Obligation management processes such as position keeping and settlement. The SOH is the entry point to Operations from a Front Office perspective.

2.3      Business Components

The following business components are part of Books & Records:

• Suspense Account Handler – this is used to track Settlement Obligations that cannot be booked into the Cash Record and/or Stock Record.
• Interest Calculation – this performs relevant interest calculations, generating the corresponding Settlement Obligations.
• Availability Check – this is a service that determines the availability of cash and/or stock to ensure that settlements will be fulfilled in accordance with contractual obligations.
• Shareholder Registry – responsible for the management of CS shareholder data. It can also contain functionality to organise and execute the general assembly (to be clarified).
• Cash Statement – responsible for the production of cash statements.
• Securities Account Statement – responsible for the production of safekeeping accounts’ or books’ statements.
• Bank Notes Inventory – handles the inventory of bank notes. Bank notes are mainly in ATM machines and at the counters.
• Settlement Obligation Store (SOS) – the golden store for Settlement Obligations with their resultant Fulfilments. SOS might also maintain the Settlement Instruction (SI) states. SOS along with the cash and stock records should provide complete and timely data to support liquidity management requirements.
• Cash Record (CR) – supports cash position keeping capability for both intraday positions as well as end-of day positions. The data store has both historic and current balances reflecting SOs and FFs as well as future expected balances based on open SOs.
• Stock Record (SR) – supports stock position keeping capability for both intraday positions as well as end-of day positions. The data store has both historic and current balances reflecting SOs and FFs as well as future expected balances based on open SOs.

2.4      Data Stores

3         Business Information Entities

3.1      Settlement Obligation

Regardless of how an SO is generated, it represents a processible settlement request containing both the obligation details (e.g. amount, currency, contractual settlement date) and the proposed fulfilment method (e.g. delivery versus payment, pay cash, transfer securities) in a single transaction. Settlement Obligations are given unique identifiers (SOIDs) that remain with them throughout their life. Settlement obligation can be one of a number of types SOs of type “Delivery” and “Booking” are currently defined but additional types may be required to support other obligations such as collateral pledges.

There is a 1 to1 or 1 to many relationship between an SO and its underlying transactions or trades; The SO generator is responsible to maintain such links, they will not be managed in Operations.

SOs are ‘versioned’ allowing a Settlement Obligation Generator to issue modification and termination requests to a previously issued SO.

During instruction and possibly matching process, a settlement obligation can be split or merged in order to optimize or facilitate the process. The result is a settlement obligation called a shape.

3.1.1      Settlement Obligation of type Booking

This represents an internal book transfer within a single CS legal entity. The Place of Settlement is internal and there are no movements between external nostro or depot accounts. The most common SO of type booking has no subtype (i.e. subtype is blank). This represents mainly the customer’s side booking when the contract is XXX meaning that the customer is booked and the bank takes the responsibility for the settlement.

3.1.2      Settlement Obligation of type Delivery

This represents a settlement where some or all of the related accounts are outside of CS or belong to different CS Legal Entities. The Place of Settlement is external (e.g. a CSD such as SIX SIS) and there is a movement between the nostro and/ or depot accounts of different legal entities.

−    SOs of type Delivery (SO(D)) subtype instruction give rise to Settlement Instructions (SI) which instruct the relevant external parties (agents, banks etc.) to execute a transaction on behalf of CS. These SOs are not marked as settled until incoming external confirmation of a matching settlement is received and matching has occured.

−    Other types of SO(D) such as subtype Dummy and Notification do not generate settlement instructions.

3.1.3      Settlement Obligation content

An SO is made up of one or more legs, each of which defines a discrete movement of a single asset. In aggregate, these legs define the Settlement Obligation. Some examples of Settlement Obligations and the associated legs are:

• Cash Payment Settlement Obligation – this would have a single Cash Leg specifying the currency and the cash amount to be paid.
• Foreign Exchange Settlement Obligation – this would have two Cash Legs, one specifying the currency and the cash amount of the base currency and the other specifying the currency and cash amount of the quote currency.
• Delivery versus Payment Settlement Obligation – this would have a Cash Leg specifying the currency and cash amount of the consideration, and a Stock Leg specifying the equity and number of shares being bought.
• Rights Issue Take Up Settlement Obligation – this would have 3 legs: 1) a Cash Leg specifying the currency and cash amount reflecting the rights issue price; 2) a Stock Leg specifying the quantity of the nil-paid rights issue stock being traded in; and, 3) a Stock Leg specifying the quantity of stock due under the rights issue.

3.2      Cash Control Equation (CCE)

The ‘cash control equation’ (See Figure 2) is a key control that is maintained by Books & Record as illustrated in the diagram below. If this equation is untrue, then it is likely that a transaction has been lost or some other error has resulted in an inconsistency.

 

Figure 2 – The Cash Control Equation

• Expected is the total cash as represented by the sum of all SOs (of type Delivery). It represents the sum of all FO[1] activities (cash flows generated in the FO) + Corporate Actions distributions (from holdings and open trades) + Correspondent Bank / Custody activities (Operations Reported Cash)
• Fails reflect those SOs which have failed to settle or have only partially settled on intended settlement date (ISD). Fails therefore are the sum of  all the differences ; ‘SO minus its corresponding FF’ or, in other words, the aggregate of all deltas between expected SO amounts and the total of all partials for that SO.
• Actual is the sum of all FFs as confirmed by external events – e.g. MT900/910 or MT103/202 with ‘097’ flag set, or confirmations in securities settlements MT544-47 for the total or partial amount of an SO.
• Unadvised are external events for which we cannot find, at that time, a matching (internal) SO. Because these events impact the bank’s liquidity, they need be processed via normal fulfilment generation. The unadvised will be zero in our model as we will automatically generate two SOs, one dummy which would perfectly matched the unadvised and a payback that would compensate the dummy (zero sum). In other words, as we use the ‘pay back pattern’ for those unrecognised fulfilments which represent unadvised cash credits.

4         Different Business Models

4.1      Introduction

Position keeping systems cannot be described without stating the overal context.

CS has different business models which are related today to the different regions. Singapore is typically based on a Broker Dealer Model while Switzerland uses different models and in particular the Private Banking one.

These models have different needs and requirements. In order to implement the TIM target, we need to understand them and build a system that support them all. We will refer to the existing functionalities and, except if these functionalities are to disappear, see how they will be reflected in TIM.

4.2      Broker Dealer

In financial services, a broker-dealer is a natural person, a company or other organization that engages in the business of trading securities for its own account or on behalf of its customers. Broker-dealers are at the heart of the securities and derivatives trading process. Although many broker-dealers are “independent” firms solely involved in broker-dealer services, many others are business units or subsidiaries of commercial banks, investment banks or investment companies. When executing trade orders on behalf of a customer, the institution is said to be acting as a broker. When executing trades for its own account, the institution is said to be acting as a dealer. Securities bought from clients or other firms in the capacity of dealer may be sold to clients or other firms acting again in the capacity of dealer, or they may become a part of the firm’s holdings.

The client (of the broker) often does not even have an account with the broker.

The broker – dealer therefore has the order, the trade, the trade lifecycle, the (best) execution and the settlement in focus.

For Brokers and Dealers the (executed) trade and the subsequent settlement is in the primary focus, assuring the broker’s liquidity and ability to deliver according to the obligations.

The position of a broker is therefore (mainly) existing between trade date and settlement date only; the dealer has a (slightly) longer term of view – but even his position is created in order to be closed rather soon again.

Only when having own books, the broker-dealer has a position over a longer time period (which is still short term compared to PB).

Challenges for the Broker-Dealer: Managing the orders and  trades  (incl. their lifecycle status), guarantee the best execution, manage the counterparty risks, control the settlement and handle overdue settlements. Managing it’s Nostro positions to guarantee liquidity (and deliverability) according to the obligations is key for the broker-dealer to stay in business, etc.

4.3      Core Custody

A custodian bank, or simply custodian, is a specialized financial institution responsible for safeguarding a firm’s or individual’s financial assets and is (normally) not engaged in “traditional” commercial or consumer/retail banking such as mortgage or personal lending, branch banking, personal accounts, automated teller machines (ATMs) and so forth. The role of a custodian in such a case would be to hold domestic and foreign assets/securities, arrange settlement, perform corporate actions (incl. handling of tax / tax reclaims), provide information on the securities regarding annual general meeting, etc.

Trading activities take place outside of the core custodian, i.e. the custodian is involved in execution of the settlement and keeps the asses and liabilities thereafter.

Positions are built over a long period of time, often as result out of several buy/sell trading activities as well as asset transfers (non trading related deliveries)  and exist over a long period.

Custodian Service requires sophisticated securities Position Keeping services with long term focus, including the knowledge of where the securities are held (deposited), whether the stock is borrowed or lent or is used as collateral; in addition, excellent handling of corporate action events (both event static data as well as execution of corporate action events) are required.

Challenges for the custodian: Keep and maintain the client’s asset and liability positions (including place of depository (custody)) over a long-term of period, perform the asset servicing (corporate actions, dividend payments, etc.), handling of tax requirements and tax reclaim, provide sophisticated reporting and analysis capabilities.

4.4      Extended Custody

Similar to the (core) custodian business model but providing more and sophisticated services such as consolidation over different custodians, performance calculation, sophisticated risk analysis, comprehensive tax reporting and tax reclaim services, etc.

Extended Custodian Services therefore require core custody capabilities, and on top of that consolidation capabilities and sophisticated and comprehensive reporting and analysis capabilities.

Challenges for the (extended) custodian: same as for the (core) custodian, in addition consistent consolidation (with inner integrity over all participating banks and assets and liabilities) and to have the underlying base data for the comprehensive and sophisticated reporting and analysis capabilities.

4.5      Prime Brokerage or Prime Services

Prime brokerage is common and widespread in the  Anglo-Saxon areas of the world.

From a content point of view the same services as with extended custodian business model are provided towards the client.

Challenges for the Primer Broker: Keep and maintain the client’s asset and liability positions (including place of depository (custody)) over a long-term of period, perform the asset servicing (corporate actions, dividend payments, etc.), handling of tax requirements and tax reclaim, provide sophisticated reporting and analysis capabilities.

Extended custodian and Prime Brokerage business model are very similar to each other.

4.6      Private Banking

Private banking normally has a long term relationship with the client in focus providing all kind of services to manage the client’s wealth for a long time (i.e. not the single trade but rather all trades as well as keeping of assets and liabilities over decades are in the focus); In addition, sophisticated problems for financial, wealth and tax planning are provided, financing strategies are developed, advisory for the entire family and for entrepreneurs is given, i.e. the overall and long-term development of the client’s assets and liabilities is in focus

Private banking requires almost all services as provided with Prime Brokerage and/or Global Custody.

Normally, the client receives a comprehensive all-in-one-stop-shop kind of package, i.e. the private bank cares for trading / dealing as well as for extended custody (the private bank takes care of all the necessary steps and actions to fulfill all the client’s needs).

Challenges for the Private Banker: same as for the (extended) custodian, in addition have the knowledge on the client and his financial aims / plans, having the specialists in all areas (research, investment consultants, tax, succession, last will, etc.) to advise and consult the client.

Credit Suisse Private Banking in Switzerland has implemented this business model.

Position keeping in PB style goes beyond the requirements of both (extended) Custodian and Prime Brokerage business models, especially support regarding PB specific requirements (see appendix for details).

4.7      Summary

 

5         Position keeping methodology in the TIM

 

5.1      Key concepts

Anonymization: All operations components must be able to work on anonymized data. The concept of the Man in the Middle allows anonymization at source and de-anonymisation when needed and authorized.

5.2      Scope: Which positions “owners”

Keeping the positions for both client’s and internal position holders is essential within a Bank no matter what business model is pursued by the respective financial institute; all client segments are served:

• Broker Dealer clients
• Custody Clients
• Prime Brokerage Clients
• Private Banking Clients
• Private Clients
• Internal Units / Internal Clients
• etc.

And therefore the following account types are in scope:

•    Nostro

•    Depot (account’s per custodian)

•    Books (Safekeeping accounts with bank’s own positions)

•    Customers’ Safekeeping accounts

•    Customers’ cash accounts

•    ….

5.3      Scope: Which “kind” of positions

The two position keeping facilities Cash Record and Stock Record are the only components maintaining positions for all types of assets and liabilities over time (within Operations); note that other units, especially Financial Control, maintain positions as well.

Treasury position systems such as FXMP (Foreign eXchange and Precious Metal Position), GM (Money Market), Physical Metal, etc. are all systems that hold positions and which functionalities include valuation. How they will be related to CR and SR has to be analysed.

OTC (Over The Counter) and other non listed securities are to be considered as well. For example in Switzerland, some insurance companies use the SR to manage their life insurances and their holders.

Own bonds: CS is issuer for bonds and has a system to manage them.

Physical owning put in CS vaults need a position system.

Registered shares are special types of positions by the issuer or its representative.

CS own shareholders’ registry is holding the number of CS shares owned by a given legal entity.

Some positions can also be “marked” and possibly the mark has an impact on the utilisation. For example, stock could be marked during a corporate action, or as lended or borrowed, or as colateral for a Lombard Credit, etc.

5.4      Scope: Which kind of dimensions

The positions can be hold considering several dimensions. The most obvious dimensions are the asset type and the ownership. The type of accounts e.g. book or safekeeping account can also be a dimension. Another dimension is the external view i.e. when the positions hold are the shadow of existing positions by other institutions. Nostro accounts or accounts by external custodians are example of such positions which need to be reconciliated and controlled.

The positions can be based on a “number of” unit e.g. 100 shares or on a valuated position, possibly in different units or currencies and using different valuation methods.

5.5      Business Processes

5.5.1      Ownership

Positions holding to define ownership of the underlying asset is the primary requirement.

5.5.2      Other purposes

• Basis for Liquidity Management of the Bank, support the Cash Equation
• Basis for the availability check of Clients
• Basis for Asset Servicing, Client Reporting and Viewings / Inquiries of all types
• Basis for fee and service price calculation
• …

5.6      Booking Processes

5.6.1      Introduction

The bookings are always derived from one of a Settlement Obligation (SO) or a fulfillment (FF). To book a fulfilment, it is also possible to need to refer to the linked shapes; this is the case when SOs were merged by the settlement engine and instructed together to the market.

A booking in any of the position systems should always contain a reference to the orignal Settlement Obligation.

The three components SOS (Settlement Obligation Store), CR (Cash Record) and SR (Stock Record) can only be fed by the SOH (Settlement Obligation Handler) and this will always be in form of a SO or a FF.

5.6.2      Internal booking

An internal booking does not require any activities with the market. It is a booking done for a given legal entity and “simply” require a transfer within the booking system.

The SOs of type booking and subtype blank are typical internal booking. When SOH receives such SOs, it forwards them to SOS, CR and SR. Possibly, for optimisation, SOH has rules to avoid sending a SO to a booking system which will have no action to perform on it (e.g. a payment to SR).

5.6.3      Expected booking

By reception of a SO of type delivery, expected booking is performed. The SO was (in delegated model) or will be (by SE) instructed to the market. The expectation is that ultimatly a fulfilment will match with the obligation. But at the time of the reception of the SO, the advise has not arrived yet.

Therefore when a SO of type delivery is received by SOH, there are first an enrichment step before the SO is forwarded to SOS, CR and SR. Possibly the SO is sent in parallel to the corresponding SE for instruction.

5.6.4      Actual booking

When the market sends an advise and VS (Validate Settlement) can match it, then VS creates a FF and sends it to SOH. SOH forwards it to SOS, CR and SR. At that moment, the expected booking is caduc and the actual booking represents the reality which conforms with the one of the external world.

5.6.5      Challenges for booking actual

All bookings should have a reference to the original SO(s). In case of shapings, the FF link to shapes, not the original SO. The booking systems will therefore need to perform some logic to trace back to the settlement obligation.

5.7      Out of Scope

Given the above methodology, the following functions are therefore out of scope:

 

6         Business Components

6.1      SOH as mediator and Operations’ entry point

SO generation in Front Office handles the trades or other business deals such as transfers and are responsible to create the settlement obligation as soon as possible. The SOM is then sent to Operations for settlement, possibly in a “fire and forget” manner unless exceptions happen or the tracking of the instructions is needed.

The principle that SOH is responsible for routing between the components has two major benefits:

• All activities are available to SOH
• The components are not directly coupled

From a booking perspective, this also means that SOH is the only component allowed to forward SOM and therefore request for booking to the different booking systems (cash or securities, target or legacy).

 

Figure 3 – Key Business Component Interactions

6.1.1      Interaction Steps

The key interactions are shown in Figure 3 with the individual steps listed below.

1. SO Generation

SO generation typically occurs in Trade Management for obligations resulting from Trade or non-Trade activities including front office, back-office and market-side (e.g. third-parties such as CCPs) sources. In some circumstances, SO generation may occur in the back office for Operations Reported Cash (OCR) events. SO-generators determine and validate SOs, either by adopting the externally provided SOs (e.g. from CCP) or by explicit generation/validation.

1. SO messages
2. SOs are submitted as SO messages (SOM) either asynchronously or as file.

Type Delivery represents external settlement, which impacts the bank’s liquidity. It encompasses ‘delegated’, ‘bi-lateral’ and ‘intercompany’ settlement models. Type Booking represents internal settlement model such as inter-book and intra-entity

1. The SO originator can amend or cancel an SO which will give rise to a new version of it being produced.
   1. Settlement Obligation Handler (SOH)
   2. Settlement Obligation Handler (SOH ) accepts or rejects submitted SOs following validation. It stores valid SOs in the SOS, provides unique SOID and starts lifecycle mgmt.
   3. SOs of type Delivery SO(D) are sent to SF. SOs of type Booking SO(B) are sent to CR/SR for booking. SOH guarantees consistency between cash & stock record bookings.
      1. Settlement Feeder (SF)
      2. SOs of type Delivery are sent to Settlement Feeder (SF ) where SSIs are added. The enriched SOs are sent back to SOH for ‘expected’ booking in the Cash Record (CR) and/or Stock Record (SR).
      3. Enriched SOs of subtype Instruction are also routed to the appropriate Settlement Engine (SE) for instruction in the market. SO of subtype Notification are ready for matching and are sent to Validate Settlement (VS).
         1. Settlement Engine (SE)
         2. Settlement Engine (SE ) performs shaping of SOs to improve settlement efficiency and risk mitigation. Shaping creates new shaped SOs with a link to the original SOs, stored within the SOS.
         3. SE then creates the Settlement Instruction (SI ) and sends it to the market. Any required external references are attached to the SOs in the SOS. Note, SIs are not created in the case of a delegated POA arrangement.
         4. In both the pre-settlement matching mode and the final settlement cycle, SE handles status advices and allegements from the market. SE also handles shaping requests post settlement for efficient VS matching.
            1. Cash Record (CR) and Stock Record (SR)

The Cash Record (CR) and Stock Record (SR) booking engines process booking requests submitted from SOH in the form of SOs and FFs.  SOs of type Delivery result in ‘expected view’ bookings, while SOs of type Booking as well as FFs result in ‘actual view’ bookings.

1. Payments Market-Side (PayMS)

Payment related SOs of type Delivery are sent to Payments Market-Side (PayMS ); PayMS is a special combination of SF and SE.

1. Validate Settlement (VS)
2. Validate Settlement (VS) matches external settlement events (e.g. MT 900/910, confirmations MT 544-47, etc.) with SOs in the SOS representing CS internal ‘expected view’.
3. Where a match occurs, VS links the FF to the matching SO or group of SOs. The FF represents the settled part of a SO (‘actual view’). There can be 0 to several FFs to one SO (reflecting possible fails and partial settlements). VS sends the FFs to SOH for ‘actual’ booking in CR/SR.
4. External events without a matching SO (‘unadvised’) are known as unrecognised FFs trigger a call to the Reproblem Agent (RA) .
   1. Reproblem Agent (RA)
   2. RA is called by VS for processing unrecognised FFs (e.g. Unadvised FFs). RA creates SOs of type Delivery (e.g. dummy SO, Payback SO) and sends them to SOH for booking and further processing.
   3. Payback SOs are manually investigated and could result in a ‘return of funds’, a ‘late match’, a ‘manual write-off’ or in a recognised fulfilment if the missing SO(D) is later generated.

6.1.2      Component Inputs and Outputs

The table below details the main input and output of the Books & Records and Settlement components involved in the core settlements processing.

6.2      Settlement Obligation Handler

6.2.1  SOID Creation, Assignment and Version Management

When the SOH receives an SO from a SOG, it must determine if the SO is new or already exists. For new SOs the SOH creates a unique identifier (SOID) that is used for subsequent processing and can be related to the SO generated by the SOG; the SO is then persisted in the SOS with this SOID. For modified or terminated SOs, the SOH retrieves the previous SO and:

• if no higher version was previously accepted, the SOH updates the status of the previously active version to ‘outdated’ and saves the incoming version as the current version.
• if a higher version was previously accepted, the SOH stores the older version in the SOS as an ‘outdated’ version.
• if a duplicate version is received, the SOH rejects the version and sends a NACK to the SOG.

6.2.2      Amendments and Terminations

Amendments and terminations are accepted from SOGs at any stage of the SO lifecycle, even after settlement has occurred. The SOH will process the amendment or termination based on the state of the previous version compared to the new version. Typically the new SO will be passed to the relevant Settlement Engine for detailed processing.

6.2.3      Validation and Checking

• Perform technical validation
• Validations include syntactic validation of the SO, checking if all mandatory fields are populated and checking if field values conform to the SO specification (e.g. as represented by an XML Schema). In addition, validations for a specific type and subtype are performed.
• If technical validation fails, the SO is rejected, stored in the SOS and a NACK is sent to the source application.
  • Validate whether status change requests received from other components can be applied. Invalid status change requests are rejected and stored in the SOS.
  • Validate the SO booking date with the current business date retrieved from the system calendar. If booking date is in the past, it will be corrected automatically and the SOG informed.
  • SOH invokes the Availability Check / Liquidity Check service to determine the availability of funds to ensure that payments can be made and transactions can be cleared and routes the response from the Availability Check / Liquidity Check services to the relevant components

6.2.4      Routing SOs and FFs

The SOH routes Settlement Obligations and Fulfilments to target business components based on routing rules:

• Route the SO or FF to the SOS, CR and SR and apply SO legs as postings in a single transaction to ensure data integrity across CR, SR and SOS
• Send SOs of type Delivery and subtype Instruction to SF for enrichment
• Send SOs of type Delivery and subtype Nnotification with no SSI reference to SF for enrichment
• Send SOs of type Delivery and subtype On_hold_instruction_rof (also known as Payback SOs) to SF for enrichment
• Route SOs that are ready for matching to the Validate Settlement component
• Route FFs received from VS to SE, for the results of the actual settlement process to be reflected.

SOH processes the ACK/NACK received from various components such as CR, SR, SOS. On receipt of a NACK, the SOH raises an exception with the Exception Handler and rolls back the corresponding postings made to the CR and/or SR.

6.2.5      Functional decomposition

6.3      SF Settlement Feeder

The settlement feeder is sometimes considered a sub-component of SOH. It has 2 main functions:

• First it is responsible to call the correct SSI enrichment function to enrich a settlement obligation so that it can be booked on one side and have all the necessary information to be instructed on the other side.
• Second it is responsible to forward to the correct Settlement Engine if necessary (SO type delivery subtype instruction).

6.4      CR Cash Record

Processing of all bookings to single accounts and actualizing of the account balances. Maintains the account records for cash accounts including balances and postings. The cash account types include customer bank accounts, book cash accounts, Vostro/Loro accounts and Nostro accounts. The system must include the ability to maintain current (real time) balances

Most of the accounts held in the CR have an impact to the balance sheet of Credit Suisse (i.e. result in assets and liabilities of the balance sheet)

Note, however, that some cash accounts (mainly contingent liabilities) affect the off balance sheet positions

6.5      SR Stock Record

Maintains the stock records for securities accounts (securities, listed derivatives, commodities, structured products) including positions and postings. The securities account types include customer safekeeping accounts, book securities accounts, and depository accounts e.g. street facing “reflection” of current positions at the external depository. The system must include the ability to maintain current (real time) positions

Most of the securities accounts impact off balance sheet positions of Credit Suisse

Only company’s own stock impact the balance sheet

6.6      Suspense Account Handler

The suspence account handler is part of the exception management process. When an account does not exist, is not known or is not active, any booking against that account is done toward a suspence account instead. Correction and correct booking is the responsibility of the Suspence Account Handler.

6.7      Interest Calculation

Typically the process of calculating interest will extract the position and sort them per value date, then the period is fixed and the calculation takes place based on the elements of the contract which might be based on defaults and usances. Once that the interests are computed, they are passed to the tax subsystem to evaluated the tax amount. Finally a settlement obligation is created and will be used for booking.

In order to calculate interest, several services from Client Static Data, Client Instruction and Client Pricing are required. In particular the following data/services are necessary:

• Calendar
• Periodic account closing date per account
• Agreement static data (which could include the calculation of the interest over several accounts)
• Usances and Defaults
• Pricing services
• Scheduler for triggering periodic account closing per legal entity
• Balances per Value Date and account (from CR)
• Tax Calculation Service (from the corresponding TIM component).
• SO generation
• Statement/Output generation (from client reporting?)

6.8      Availability Check

6.8.1      Availability check

Availability check is done on the customer side. It is checked whether he/she has enough cash and/or enough securities.

6.8.2      Liquidity check

Liquidity check is done on the bank side. It is checked whether there is enough cash on the Nostro to be used or on the account by the custodian for securities.

6.8.3      Different kind of checks

There is not a single kind of availability check. For cash, the check can be done on a given account, over all or some accounts (e.g. having a given currency), using a fixed credit limit, possibly using a limit based on a Lombard credit, etc.

For securities, this can even be more complicated, based on the custodian, on blockings (e.g. not available because of Lombard credit or on going corporate action or employee’s stock). In case the securities is lended, this might also trigger a re-allocation processing from the SLB system.

6.8.4      With or without reservation

A check can be done in order to reserve the asset in case of success. The reservation can be fixed or can expire after a certain period. A fixed reservation must be explicitly cancelled or used by the trade (possibly partially or over drafted).

6.8.5      With or without a token

The reservation can be done based on certain characteristics of the trade and the system has rules for matching the reservation with the trade or the reservation gets an identifier or token that needs to be provided when the asset will be booked.

6.8.6      Over several systems

In PB Switzerland, as soon as the ownership has been transfered after buying securities, i.e. the trade is done, it is possible to sell. This means that the availability is computed over the booked assets as well as the just executed trades. At the time of this writing, the following systems are involved: WS-Infra, DBH and TOM.

6.8.7      Difference cash and securities / Fongibility

Availability or liquidity check is also depending whether the asset is fongible or not. For example a named share or a bond chosen by the lottery cannot be replaced by another.

6.8.8      Cash and currencies

The last point to take into consideration is the currency for the cash part. For a given trade, several currencies can be involved. The customer pays from his account that has a given currency. The asset been bought can have a price in another currency. Fees and taxes can also involve other currencies e.g. EU WHT is always in Euro. Some of these amounts are cash out, other are in a first time only booked.

 

6.8.9      The reservation system

The reservation system is intimely linked with the book of records. It must not be possible to use reserved asset by another request than the one linked with the reservation. Therefore the systems need to work in symbiose.

Today on SBIP for example, the reservation system is part of XBS for cash and under the control of DBH for securities.

6.8.10   Time point of check and consequences

Availability check time point

Typically, private banking does not allow its customers to go short. Therefore the availability check is performed before each trade and if the customer does not have the corresponding long position, he cannot sell. Similarly, if he does not have the cash, he cannot buy. Therefore the check is preventing the trade to happen and must be done before an obligation is created.

Normally, the trading system requests a check and blocks till it gets the result. Possibly, it could set a time out to get a response or to refuse the transaction. To avoid race conditions and to insure a timely answer, these checks are done today synchronously.

The bank keeps the external positions and the booked positions reconcilled, therefore except if there are breaks, the external position also exist when a customer has a long position (except certain cases of SLB…).

Conclusion: the availability check is done before the trade timestamp.

Liquidity check time point

For liquidity check, this is different. First, the time point is on settlement date. It makes no sense to make a reservation over a few days on a Nostro account. Cash management has to insure that the cash is on the Nostro in a “just in time” manner, possibly borrowing cash from the Central Bank. Also the customer must not be prevented to conclude a deal because the bank is not able to provide cash or securities.

Of course, extra-ordinary events could force the bank to react differently (e.g. what happened in Greece in 2015).

 

6.8.11   Availability and Liquidity checks in TIM 2.2

Depending on the SO type (booking or delivery) and subtype (funded, instruction), it is expected that SOH performs availability or liquidity check. Typically, a SO of type booking would be linked to an availability check while a SO of type delivery would be linked to a liquidity check.

Certain subtypes would also be used to reserve or remove a reservation.

TIM defines 2 components for performing the checks called LiqCheck and AvailCheck.

The author believes that liquidity checks should be done by the settlement engines at settlement time. Therefore they would not be done by SOH when a SO of type delivery subtype instruction arrives.

Availability check should be done by the Order Managers synchronously. Which type of availability check cannot be defined by SOH and most of the time the checks must be done as fast as possible, without going through a series of asynchronous calls. The order manager can inform SOH afterwards in case the information is needed by other components (e.g. SOS).

Another reason not to put the check within SOH is the needed synchrononization between the SOM(booking) on the client side and the SOM(delivery) on the market side. If the check is done in the order manager

See also the document “Availability/Liquidity check, GPP and TIM” for more details.

6.9      Shareholder Registry

Here there are two types of shareholder registry. The first one is the system that maintains the CS shareholders and possibly manages the general assembly and all the correspondance linked to CS own corporate actions.

The second one is the system that processes and maintains the information about registrated shares on behalf of the customers. During settlement, the Settlement engine needs to recognize that the shares are registered shares and produce the necessary instruction for transfering the shares to the new owner.

6.10   Cash Account Statement

Each time cash is booked in CR, a corresponding statement is created. The cash account Statement component normally only prepares the data. The data is then merged with CID information and sent to output management for creation of the statement in the correct form and support.

6.11   Securities Account Statement

Similarly to cash, each time securities are booked in SR, a corresponding statement is created. The securities account Statement component normally only prepares the data. The data is then merged with CID information and sent to output management for creation of the statement in the correct form and support.

6.12   Bank Notes Inventory

This is the inventory of cash in form of bank notes that are either in ATMs or by cashiers. The location of these bank notes and the corresponding currencies are the most important information that needs to be kept, together with the ownership i.e. the legal entity.

6.13   Functionalities not placed in the B&R components yet

From a private banking perspective, several position keeping systems are used today for different products and different goals. These position keeping systems have all valuated positions and are used for profit and loss calculation or performance calculation.

ALIS (Asset and Liability Information System) groups positions from the different other position systems and provides many global customers’ reports. It also delivers DBH with the securities’ positions valuation. There are even the possibility to have shadow positions for safekeeping accounts hold in other financial institutions.

FXMP (FX and Precious Metal Positions) summarizes netted positions and is used to calculate P&L and provide valuation.

GM (Geld Markt or Money Market) has the cash positions which are valuated by Deripro.

Another application has the bank notes and physical precious metal positions (tbd which one?) and OTC positions should also be held in a systems. Some of the safe positions are booked in XBS accounts.

For the CS own short term bond (Kassa obligation), the application EIGKO handles both the processing and the positions.

The books and CS own positions are valuated in SAVAS.

SLB (Securities Lending & Borrowing) manages the corresponding positions (available, lended, borrowed).

Tax lot accounting and acquisition price management are tighly coupled with position handling and are in scope of CR/SR at the moment. But is it the right place?

Liabilities are also hold in safekeeping accounts’ like positions. For example mortgages or credit appear as such on the internet DirectNet application.

6.14   XXX

6.15   XXX

7         Data Stores

7.1      Settlement Obligation Store

 

7.1.1      Summary

• SOS is the golden store for SOs and FFs – persists all information relating to SOs and FFs
• SOS maintains Settlement Instruction (SI) states
• Maintain linkage related information
• Linkages between SOs
• Linkages between SOs and FFs
• Linkages between SOs and shapes
• Linkages between SOs and SIs
  • Archive SOs and FFs after a pre-defined period
  • Maintain detailed audit trail on SO and FF lifecycle
  • SOs
  • FFs

7.1.2      Business entities maintained

7.1.3      Description

SOS contains all the settlement obligations and the fulfilments. From a booking perspectives, it is possible to retrieve SOs and FFs given their identifiers in a bi-temporal way. The booking systems therefore do not need to keep all the SOs and FFs locally.

SOS will also store the ack/nack linked to booking requests’ answers.

SOS is a store as well as a component on its own. Many components have their local store such as SE or VS, but in the case of SOS, it is the golden source and the main store for Operations.

The SOS’ content can be summarized as:

• Settlement obligations (SO) for all asset classes and all asset movements.
• SOs are the contracts between FO and BO for settlement requests.
• SSI enriched SO: per definition the SO is ummutable with the exception of SSI enrichment.
• Shapes in case the Settlement Engine (SE) creates them for SO of type delivery subtype instruction.
• Fulfilment (FF) for matched advises, created by Validate Settlement (VS).
• Linkage information between the different entities: SO between themselves, SO and shape(s), SO and/or shapes with fulfilments, manual match of group of SO/Shapes with group of FFs.
• Linkage between instructions and SO and/or shapes.
• Status for all entities of type SO, shape or FF, possibly some of the status for instruction or unadvised advises (tbd).

SOS is as well an operation store as a golden reference over years, used for reporting, monitoring and inventory of all versions.

SOS and LE local store(s) have differences and similitudes:

• SOS is a global store for all asset classes and in particular for SO of type bookings.
• SE has only SOs of type delivery, possibly only for certain asset types and/or markets (e.g. payments, cash, securities, Russia) possibly only for certain currencies (e.g. payments).
• SE has a subset of “active” SOs of type delivery and shape. SE does not need to keep history as it could get the information back from SOS. SE does not have fulfilments. SE has only part of the statuses (e.g. booking ack/nack are not in SE) and part of the links.
• SE could be COTS (e.g. GPP for payments with Clear To Pay), could be outsourced (e.g. HSBC?) and could therefore have a store difficult to access.
• SE is responsible for Instructions and their states. SE interacts directly with the markets.

Considering SE as a pure instruction and pre-settlement matching engine, it will never get all the information around settlement obligations or shapes. Discussions are open to whether SE should get settlement information. In order to keep the components loosly coupled, this should be avoided and the cleaning of the local store should be only based on time.

The question whether SOS or SE local store is the master depends on the entities’ types and the definition of master.

• The master is normally the store that is updated first and the slave holds read-only copies of the data.
• The master is where applications interested to get data are allowed to get them from.
• The master is the place where the data is supposed to be correct. This means that if there are differences between two stores, the master “wins”.

 

• In the TIM philosophy, SOS is the store where data can be gotten from. There should be no direct access from non SE components to a SE local store.
• Open point: SI’s states to be stored in SOS? Or only forwarded from SE to SOH to any interested components? Prefered
  : canonical model for SI states stored in SOS.
• SE’s local store is the master for SI as they are not stored in SOS.
• VS’s local store is the master for advises as they are not stored in SOS.

Also a master’s content has normally a longer life than a non master because the later can re-fetch the data from the master.

The needs will be quite different depending on the “age” of the last version of a SO.

• SOs ready to be matched must be monitored and are the basis for fails management.
• They are also the basis for risk management (over all asset classes):
  • Counter-party risks: aggregation based on counter party
  • Interest claims (e.g. unmatched particularly in Repo and SLB business)
  • Reputational risk (e.g. when a customer could not use its voting rights because of wrong or late entries in AREG).
  • Generic risk linked to bank business…

Implication of SOS in monitoring, fail management and error management:

• The short term view is used to monitor the settlement process covering the period between T and T+3 for example.
• The monitoring is on the market side for instructed SOs/shapes but also in the internal sides (e.g. SO were booked, checks were passed, SO was handled to correct SE within pre-defined time frame)
• SOS content will support the troubleshooting process.

Auditing could be a SOS functionality or another mean such as audit files can be used. Regulatory audit has other requirements as a simple audit to be able to reconstruct the interaction. In any case, the following have to be considered:

• SOH is the entry point for SOs coming from FO.
• FO could be a external company/bank.
• SO represents contract.
• SOH must conserve a trace of what it has received and can either do it in files or in SOS.
• In the later case, SOS would act as audit trails for contracts received from FO.

SOS been the unique store getting all settlement obligations, it is the starting point for many reports:

• SOS grouping information on all asset classes, it can be used as base for reporting, avoiding having to aggregate the data from different stores which could be inconsistent.
• Being a global repository, reporting is simplified as there is only one format per entity (SO, shapes or FF).

Considering the intra-day position management e.g. for cash management, SOS is a important component:

• Cash and Stock Records have the booked balances, possibly some reservation.
• The active SOs have the deltas that will be applied to these balances in the short Future, but the exact point in time is not known with certitude.
• Cash management works with algorithms that are based on probability to occur at a given point in time.
• SOS is therefore an important store to base cash management on.
• This will be developed in the cash management documentation.

Finally, the key benefit of SOS could be summarized as follow:

• Central store (only one)
• Internal store (e.g. within Ops)
• Globally accepted entities’ format and stored information.
• All asset classes (i.e. single repository independant of SO generators)
• All obligations
• Near real time updated by all actors (directly or indirectly: FO, SOH, SF, SE, VS, RA).
• Long history period
• Bi-temporal views
• Audit trails of changes (e.g. version handling, status, links)

In the target state, operations should not contain any CID (customer identifying data). As it is not always possible, some CID data will be anonymized in a bijective way that allow to retrieve the original when needed. The man in the middle converts back and forth between anonymized data (anonymization at source) and stored data. Considering the man in the middle, it is important that the only mapping between CID data and operations’ data can be done through the man in the middle. The consequence is that the SOID should not be known from FO and that only operations’ components are allowed to generate them. Front to back monitoring needs to go through the usage of the man in the middle and SOS should only have anonymized data.

 

7.2      Cash Record

7.2.1      Description

From a store perspective, Cash Record supports multiple legal entities and is responsible for the following functions

• Aggregate and hold [A10] cash balances for in-scope accounts by currency
• Maintain current views of balances: Aggregate and Hold current (near Real-time) view of cash balances.
• Maintain bi-temporal [A11] views of balances: Aggregate and Hold ‘As-At’ End of Day view of cash balances, with respect to the applicable Business Calendar
• Maintain balances by intervals: Aggregate and Hold Balances by Intervals – maintaining both Start and End of Interval quantities, where interval boundaries coincide with applicable business date boundaries.
• Maintain ownership (e.g. book level) and location/entity (e.g. nostro account) view of cash balances
• Maintain Balances by Trade Date and Settlement Date. Aggregate and Hold ‘Traded’, ‘Expected’, ‘Unsettled’ and ‘Settled’ view of cash balances, where Expected = Unsettled + Settled
• Maintain Balances by Product Lines and Functions (i.e. Product Sub-Types): Aggregate and Hold Product Sub-Types view of cash balances – covering a variety of types ranging from Front Office, Asset Servicing or Operations Related Assets
  • Validate SOs and FFs received from the SOH
  • Validate presence of required fields (schematic or contextual – i.e if mandatory based on type of event, SO/FF etc) in SO and raise exception if validation fails
    • Process new SOs, FFs and related events
    • Process SOs, FFs and other relevant event notifications (e.g. Shaped SOs originating out of Settlement Engines)
      • Process new versions of SOs and FFs
      • Process reversals or adjustments to postings created for the previous version
      • Handle versions received out of sequence (e.g. raise an exception followed by subsequent replay if necessary)
        • Access SOS data interfaces when required for any data linkages not available to the Cash Record
        • Record SOs and FFs received from the SOH. SOs of type Delivery result in ‘expected view’ bookings, while SOs of type Booking as well as FFs result in ‘actual view’ bookings.
        • Record asset movements and postings
        • Send ACKs back to SOH for messages received and processed successfully. In the case of failures, send NACKs back to SOH. This enables SOH to support a real-time monitoring control between the Stock Record and Cash Record.
        • Maintain data to ensure integrity (internal, external, front to back etc).
        • This includes controls to ensure adherence to the Bank Control Equation (See Figure 2).
          • SO details pertaining to the cash leg in form of movements and positions

7.2.2      Business entities maintained

7.3      Stock Record

7.3.1      Description

From a store perspective, Stock Record supports multiple legal entities and is responsible for the following functions

• Aggregate and hold securities positions for in-scope accounts
• Maintain current view of balances
• Maintain bi-temporal view of balances
• Maintain balances by intervals
• Maintain ownership (e.g. book level) and location/entity (e,g, depot ) view of securities positions
• Maintain Balances by Trade Date and Settlement Date Dimensions
• Maintain Balances by Product Lines / Functions (i.e. Product Sub-Types)
  • Record SOs and FFs received from the SOH
  • Process new versions of SOs and FFs
  • Record asset movements and postings

7.3.2      Business entities maintained

• SO details pertaining to the securities leg in form of movements and positions.

7.3.3      Active vs. passive stock record

XBS and DBH, the PB Switzerland existing booking engines, book what they receive. In other words, no rules are applied. GSR receives a booking request and applies rules depending mainly on transaction type and product type to determine how it has to book. Part of this processing is done today for cash in NBS which prepares data for finance as well as for the cash subledger.

The different business models used within CS mean different requirements that are contradictory. From a broker dealer point of view, double sided booking is a must. From a custody business point of view, some transactions have the other side “outside of scope” or non existing. For example booking a fees have the other side in a Profit and Loss account that has no counterpart in nostro or depot.

A naive problem creating a dummy account representing this “non relevant” account in order to book double sided would bring enormous desadvantages. For example there would be so many postings towards the account that it would be the bottleneck for booking and particularly for batch processing. On top of that the balance associated with this account would have no meaning or usage.

Event if DBH is single sided, it has a link toward SBH that represents something similar to the “other side”. In each DBH position, there is a reference to the depot representing the location of the asset (custodian code + rubric code). This is one of the main reason to have different “sequences” for a given financial instrument’s position, ultimately representing different positions.

8         Position Keeping

There are common functionalities for position sytems, in particular, they are the legal Master store of all cash and stock positions and balances.

They must maintains Intraday and End Of Day (EOD) positions across the significant dates (Trade, Value, Settlement, etc.) and Dimensions (Counterparty, Client, Book, Currency, Account, etc.).

Stock Record is the parallel to the Cash Record for securities. There are big differences, in particular, the cash is fungible while the elements in the Stock Record are not. From a private banking perspectives, there should be a corresponding location for each securities’ position, this is not the case for cash… The sum of the cash balances is not in to be found in Nostros.

8.1      High level BOM and considerations for securities’ position keeping

The following BOM shows the main concepts around position keeping, in particular, the movement, the booking , the account, the blocking and the position. The fact that the positions reflect several rights and obligations is predominant. The different booking dates reflect the fact that these rights and obligations are tranfered at different point in time and can be separated (e.g. for securities’ lending and borrowing).

The booking system must be able to handle all the rights and obligations. During settlement, the timing of their transfer differs, once settled, they can stay “together” for a long time in case of retail customers for example. For certain customers e.g. doing lending and borrowing, the rights and obligations can “go apart”. The booking system must be flexible enough to reflect this reality.

Business must decide on the strategy that needs to be used. On a pure “counting” side, the booking system could be seen as only a reflexion on the external positions (nostro, depot) with corresponding ownership (book, customers). The consequence is the need for a “parallel” accouting in the Front Office with links to risk management and offering the functionalities needed for all business models.

On a “unique” position system side, all the needed functionalities must be present. In particular, valuation is not an operations functionality but keeping the valuated positions is a must and could be done by operations. Availability is also such a function as it strongly depends on clients’ management and therefore Front Office.

The acquisition price can be kept at the movement level. Acquisition price at the position level is depending on the method(s) to be apply, which might depend on the customer’s wishes, customer’s nationality and domicile, tax regulations, etc.

In any case, accounts related to Profit and Lost must not be managed.

Depending on the strategy, the non functional requirements can differ significantly: Access to the positions from the outside world e.g. DirectNet or views e.g. GUIs from XBS or DBH for the RMs puts enorm pressure on performance (retrieving positions, possibly valuating them on the fly, etc.).

8.2      Key concepts of position keeping in the TIM

8.2.1      Position separating attributes or position building attributes

The position building attributes have different goals. The primary one is to identify the financial instrument. There is no single system offering an identifying key for listed financial instruments and on top of that there are instruments that are not listed. Therefore there will be several attributes defining the instrument for a position. An example iare the exchange traded derivatives (ETD) treated as separate financial instruments reflecting the correct maturity date, style, strike price, serie, contract size, etc. In certain cased, the currency is also needed to specify the financial instrument.

Another dimension is also done on the rights and obligations. This is important during settlement, starting with moving the ownership before moving the “physical” holding. The rights to vote at the general assembly or to receive results of corporate actions are other kinds of rights that might be present or not e.g. by Securities Lending and Borrowing, the rights get apart, between the holding and the corporate action. This dimension can also be present for the building of the position.

An important information is the “physical” location, particularly for securities. A customer having bought the same instrument but for any reason in different venues and/or custody by different custodians will get seggregate positions for the same instrument.

SBIP specificities: some financial instruments such as the US Limited Partnership ones are kept in different safekeeping accounts and have hard control. Indirectly such instruments have positions building “attribute” in form of a specific safekeeping account type.

Of course the position is within a certain legal entity, for a given customer or the bank, for a given account.

There is the need to be able to see that for all the positions in customers’/bank’s safekeeping accounts/books, the corresponding physical location is known and that for all physical locations we know who are the owners. On the physical side, an account can be used for several owners (e.g. omnibus account, account seggregated by nationality or individual accounts).

While it might be possible to simply put cash in one account without further characteristics, it is necessary to build “subposition” for stock. Consider for example a safekeeping account for a customer who has bought the same financial instruments on different venues and for which different custodians are involved. It is necessary to know this information, on one side for reconciliation and on the other side for availability check and fees calculation when reselling.

Position separating attributes required for prime brokerage, custodian services and private banking. The following attributes have to be considered:

Legal Entity Identification

Securities Account Identification

Financial Instrument Identification

Attributes to individualize the «template» for certain financial instruments such as e.g. bank issued medium-term notes (“Kassenobligation”), German borrowers notes (“Deutsche Schuldscheine”), etc.:

Individual maturity date

Individual interest rate

Individual interest payment date

etc.

Depository (Custodian, at least country of custodianship)

Trade Currency (for position cost price view or securities which are traded in different currencies)

Note that exchange traded derivatives (ETD) are considered to be modelled as separate financial instruments (thus reflecting the correct maturity date, style, strike price,  and series (i.e. individual series of ETD  lead to separate FI), contract size, etc.). If this is not the case some additional attributes (e.g. strike price, series, etc.) are required on both posting and position level to differentiate between the individual positions

8.2.2      Required Position (balance quantity) views

The following position views must be supported:

Trade date oriented view reflecting the ownership view on the position

Allows asset servicing services for e.g. equities, etc., which pay income based on the trade date oriented view

Serves as basis for GIPS compliant performance calculation

Allows asset based reports based on ownership view and reflects the client’s risk position

Settlement (or value) date oriented view reflecting the possession view on the position

Allows asset servicing services e.g. for bonds in certain markets, etc., which pay income based on value date oriented view

Note that in Private Banking business the client normally has a “one-stop-shopping”  (so-called order room) approach (i.e. Credit-Suisse is both broker and custodian) and therefore applying a contractual settlement accounting (i.e. Credit Suisse guarantees the settlement of the securities according to the contracted settlement date no matter as per when our counterparty settles); note this is normally called contractual settlement date accounting (CSDA)

Note, however, especially in the non-order room business Credit Suisse normally offers actual settlement date accounting (ASDA) only; however for some institutional clients contractual settlement date accounting (CSDA) is offered by Credit Suisse in exception situations

Possession view equals to the location view if all settlements take place on time, i.e. possession view and location view shows a difference in case of overdue settlements

Booking date oriented view (please refer to the slide in the appendix defining the booking date for more information) reflecting the view as per when the given movement has been registered in the books of Credit Suisse, and as per when (in which period) it will be shown on the tax reports or asset based reports

This balance type is often materialized, i.e. the position quantities are shown over time based on booking date as the booking date view is the only view only moving forward (no backdated postings possible thus allowing as-of and as-at trade date and value date views)

Booking date oriented view is required to provide as-of and as-at views (in conjunction with trade / value date) over time

Booking date oriented view is often used for period assignment, i.e. booking date truly determines the correct period assignment of a transaction

The booking date is also of big importance for the delivery towards financial control (for the balance and P&L sheet of Credit Suisse)

Note, however, that in todays legacy system (SBIP) the booking date of cash and securities postings of the same business transaction may refer to different dates in some rare situations (i.e. the booking date exists on both cash and securities posting and may diverge); this must be handled at least in the coexistence phase of the involved position keeping systems

8.2.3      Position Keeping principles, capabilities and scope

The following capabilities must be supported:

• Keep / maintain the posting of all kind of financial instruments (securitized instruments and goods being represented in the financial instrument static data (VDPS))
• Support all book date, trade date and value date oriented views
• Not the single trade (or even parts of the operational processing of the trade) but rather the sum of the trades/transactions determine the position; the quantity balance per date (booking ~, trade ~, value date) for an entire account must be retrievable fast
• Support the concept of the details of custodian / depository (i.e. account and custodian to support segregation); Allow for back-dated position views (along the different date views) including support of as-of and as-at inquiries for up to 10 years (on the other hand an archiving process needs to be in place which cleans up postings which are older)
• Allow Single sided Postings for all asset classes in order to fully support receive free, deliver free and/or postings towards P&L accounts, which are held within Financial Control (Accounting) only
• The non-settled position is of less interest as the position is held for quite a long time, normally (i.e. the few days required for settlement disappear in the course of many months or even years in which the position is held); however, the non-settled position is of relevance for asset servicing if market claims are necessary (e.g. if settlement took place EX whereas CUM was contracted)
• Support the concept of reservations, blockings and position separating specialties (e.g. for collaterals, annual general meeting, securities lending and borrowing, missing coupon sheet, not checked for authenticity, etc.)
• Allow for position consolidation to omit certain blockings and specialties in reporting and viewings
• Support comprehensive and consistent (!) position views spanning over all asset (and liability) classes (cash, securities, commodities, etc.)
• Allow position keeping for all type of instruments (and assets/liabilities) which may be held in a safekeeping account (according to Swiss law), such as securitized instruments, ETD, etc., but also insurance policies, real estate borrowers notes, sealed and open envelopes, bank issued medium term notes (“Kassenobligationen”), German borrower’s notes (“Deutsche Schuldscheine”), etc.
• Not only the position quantity is of interest but also the information around the posting / transaction (e.g. involved fees, taxes, cash amounts, etc.)
• Support for large accounts having thousands of positions allowing fast access to the trade date oriented position quantity balance as per yesterday
• Support the concept of booking date including booking date roll
• Optional: Capability to calculate average cost price / value on position level (gross and net, i.e. incl. and excl. fees)
• Optional: Support for FIFO / LIFO chains and explicit liquidation of positions (dependent on tax law requirements)
• Optional: Support for calculation of realized profit and loss (incl. and excl. fees and/or tax)

8.2.4      Blocking concept

A position can be “reserved” as it is often the case during trade capture to make sure that the customer never goes shot.

A position can be “blocked” over a certain period such as employee’s stock, where the employee can get corporate action result but cannot sell or use the stock as collateral for example.

A position can be “marked” e.g. for on going corporate action.

A position can be “marked” for securities lending or borrowing. So either as available for SLB or as lent.

A position can be “restricted” or “out of regulation” e.g. when nationality or domicile of owner changed and the position is now under a new set of regulation’s rules that would prevent the owner to be allowed to hold such positions.

These characteristics can be exclusive or combined. The existing system has many different kind of blockings and new ones can be defined. The new systems must be at least in the position to take over the existing data but normally should offer the same level of functionalities.

Existing positions have also

• Acquisition price (including details of fees)
• Valuation per end of last business day
• Realized and/or unrealized P&L
• Periodical fees
• Views per different dates: trading, booking, settlement, position creation date, last closing date, etc.
• Tax Lot accounting

The positions can be real or virtual (simulation or shadow), they can be for any financial instrument for which CS keeps reference data and assigned a unique identifier. In PB Switzerland, this is not only listed securities, this can for example also references something in the vault.

9         Booking date challenge

There is a requirement that a calendar TIM component defines the booking date per legal entity. SOH should use this booking date to check the SOM and possibly correct it.

Theoretically, the day roll over must be the same for cash and securities. In this context, there could be a component that “decides” that the time has arrived to roll over (possibly by getting a request from FO) and from then on everything is booked with the new date. In a decentralized asynchron world, this is not obvious, if not impossible to implement.

First for SOH to check for the booking date: either it is continuously asking the calendar for the booking date or it is caching it. The first problem is a very ineffective one and does not prevent SOM with the old booking date to arrive after SOM with the new booking date in the booking systems (in particular if there are emulators or adapters). The second problem does not work as there will be a delay between the day cut off and the usage of the new date. And because there are several listeners in SOH, they cannot be synchronized to switch the date.

Second for the booking systems to use that date: from an accounting perspective, the booking date is a technical date when the booking was put into the system. A booking system cannot book with an old booking date. Some processes have to be processed a given booking date: closure and interest calculation on cash account must be booked the last business day of the period. In PB Switzerland, the booking system does nor roll over as long as these “mandatory” processes have to successfully completed. These processes are often batch process, it is not possible that part of them is done on one booking date and the other on another date.

Because cash and securities are not booked within the same technical transaction, there are cases today where cash and stock are booked on different booking dates. For PB Switzerland, the delivery applications provide a booking date but the booking systems ultimatly define their booking date and a warning can be returned. Most of the providers do not get the warning because they would not process it. Only the FX leveling application wants to get informed.

The exact business requirement for FO to control the booking date is not known to the author. The suspicion is that reconciliation would be simplified and lead to less breaks. So why no introducing a reconciliation date/periode and not use a date that belong to the booking systems?

The rare cases when cash and securities are not booked with the same booking dates and pose problems should be analyzed. Same thing is true for Nack handling of booking, which are much more subject to problems.

From the author’s point of view, if reservation took place for the debit side (cash or stock), the – normally within milliseconds – difference of time between the bookings does not represent risk. Otherwise race conditions could lead to usage of assets that should no more be in the positions.

 

10      TIM Conformance

Description of how the Business Subsystem support the design principles of the TIM and the rationale behind any exceptions.

 

See more for _Private