UT-PBR-044 Processing of Static Data maintenance instructions during the night-time settlement (INC000000163836) Introduction This note describes the different design options proposed, along the project lifecycle, to manage the processing of Static Data maintenance instructions during the night-time settlement, in order to further explain (in addition to the information already provided in the ticket work-log) how the current software behaviour is in line with the latest design option retained in this area (as of GFS v.3.0). Furthermore, the notes illustrates some of the drawbacks that would result, within the current design, from allowing the queuing of multiple Static Data maintenance instructions insisting on the same object. Finally, the note identifies the possible options that can be selected at this stage as a possible way forward. GFS v.1.0 and v.2.0 (until May 2009). Within the original design, the Static Data Management processes were fully synchronised with all T2S settlement processes. This implied the need for the T2S application to be able to manage concurrency between different T2S processes and possible side-effects of static data changes on the T2S settlement processes. For this reason, five different scenarios were identified, one of them specifically concerning the processing of static data maintenance request during the night-time phase. As described below (see scenario 5), the original approach adopted during the night-time phase was just to queue all static data maintenance requests received during a settlement cycle. In other terms, all requests were simply put on a Pending status (informing the relevant T2S Actor) and all of them were then processed only by the end of the ongoing settlement cycle. This approach, inter alia, would have allowed what you are requesting for, i.e. to submit many static data maintenance requests on the same object, even though all of them would have been processed only by the end of the settlement cycle and without necessarily following the same sequence used by the T2S Actor to send these maintenance requests (owing to the parallelism of the architecture). Maintenance requests processing Depending on the specific request and on the type of static data object involved, each maintenance request submitted under the two eyes principle is processed according to one of the following scenarios 1 : 1. Maintenance request processing not concurrent with the settlement process 2 and without possible sideeffects on it. The request is either related to a static data object that is not relevant for the settlement process, i.e. that is not checked or changed in any way by the settlement process (e.g. update of a party 1 The aim of what follows is only to describe the expected behaviour of the concurrent processes from a user perspective and not to provide a specific technical approach. It will be part of the software design process to evaluate the different possibilities and to select the optimal solution for the management of concurrent processes. 2 In this context, with settlement process is meant the whole set of processes (i.e. validation, matching, settlement and so on) handling instructions in T2S, from their arrival in the system, until their settlement (or rejection).
address), or not meant to be immediately valid (e.g. closing of a securities account as of a future date). In this case, the request is processed immediately and the requested change is applied. 2. Maintenance request processing with possible side-effect on the settlement process. The request is related to a static data object whose change may have an impact on the settlement process (e.g. update of the tolerance amount for a specific currency and threshold), i.e. the object is checked but not changed by the settlement process. In this case, the request is processed immediately and the requested change is applied. Then, a maintenance notification is sent to the LCMM domain, so that the set of all individual settlement instructions not yet settled and possibly impacted by the change can be revalidated against the new data (see below the description of the Notify Maintenance function for more information). 3. Maintenance request processing possibly concurrent with the settlement process. The request is related to a static data object that may be used concurrently by the settlement process (e.g. creation of a new restriction on a securities account). In this scenario, two sub-cases are possible: 3.1. No settlement transactions that may use concurrently the relevant static data object are in the settlement in process status (see the Validation, Provisioning and Booking module of the Settlement domain for more information). The maintenance request is processed immediately and the requested change is applied. In the meantime, no other settlement transactions that may concurrently use the relevant static data object can reach the settlement in process status. 3.2. At least one settlement transaction that may concurrently use the relevant static data object is in the settlement in process status. The maintenance request is not processed until all the relevant settlement transactions leave this status and no other settlement transactions that may concurrently use the relevant static data object can reach the settlement in process status. When the last relevant settlement transaction leaves the settlement in process status, the maintenance request is processed and the requested change is applied. Also during the maintenance request execution, no other settlement transactions that may concurrently use the relevant static data object can reach the settlement in process status. 4. Maintenance request possibly concurrent with the settlement process and with possible side-effect on it. This is a combination of scenarios 2 and 3 in which the request is related to a static data object that may be used concurrently by the settlement process and may have an impact on it (e.g. closing of a T2S dedicated cash account). In this case, the request is processed as described for scenario 3 and the requested change is applied. Then, like for scenario 2, a maintenance notification is sent to the LCMM domain, so that the set of all individual settlement instructions not yet settled and possibly impacted by the change can be revalidated against the new data (see below the description of the Notify Maintenance function for more information). 5. Night-time maintenance request. Regardless of the relevant static data object, two sub-cases are possible: 5.1. The request is received during a settlement cycle. The maintenance request can not be processed immediately. T2S sends immediately a message to the sender, just to confirm the reception of the request, whose status is set to Pending. The request is eventually processed at the end of the current settlement cycle and the requested change is applied. 5.2. The request is received between two settlement cycles. The maintenance request is processed immediately and the requested change is applied.
In case of a maintenance request submitted following the four eyes principle, such a request is processed immediately anyhow (i.e. regardless of the specific request and the type of static data object involved), but the requested change is not made active, waiting for a proper maintenance approval request. From GFS v.3.0 (October 2009) In the summer of 2009, the market requested two main changes in the design of the Static Data Management processes: 1. to remove the synchronisation between the Static Data Management processes and the T2S settlement processes; 2. to process immediately Static Data maintenance requests during the night-time phase, by differentiating between changes affecting or not affecting the T2S settlement processes. The first change in the design reduced the possible scenarios occurring during the daytime phase from four to one. In addition, it required a clarification on how to avoid potential technical or business data inconsistencies stemming from the above mentioned lack of synchronisation. The second change in the design was requested in order (a) to allow the majority of the possible static data changes (i.e. the ones not affecting the T2S settlement processes) being processed immediately and (b) to reduce as much as possible the processing to be performed by SDMG between two night-time settlement sequences. This new approach, differently from the previous one, envisioned the immediate creation of the new revision of a given maintained static data object, without waiting (even for static data changes affecting the T2S settlement processes) for the end of the night-time settlement sequence. In particular, for static data changes affecting the T2S settlement processes, the new revision of the changed object was set in a Queued status, i.e. a transient status between the Approved status of the previous revision of the object and the Approved status of the newly created revision of the same object. This is the reason why, with this new approach, a Queued static data object cannot be further updated. The below GFS excerpt describe the SDMG behaviour when taking into account the two design changes just described. So, in a nutshell, the new design choice adopted for the night-time phase allowed removing any limitation on the processing of static data maintenance requests (when they are related to changes not affecting the T2S settlement processes) and performing immediately at least the business validation of all the static data maintenance requests related to changes that affect the T2S settlement processes. Compared with these advantages, not having the possibility to submit multiple static data maintenance requests on the same object was not considered a significant restriction, especially when considering that a single static data maintenance request can of course convey updates of many attributes of the same object. The current SDMG design is still founded on the design option adopted in GFS v.3.0. Maintenance requests processing Reference Id SDMG.ALL.SDM.2.1 Depending on the specific request (i.e. on the type of static data object involved), {T2S.16.190} and on the phase of the settlement day, each maintenance request submitted under the Two-Eyes principle is processed as follows.
During the daytime processing, this function processes the request and applies the requested update immediately. If the request updates a static data object or an attribute of a static data that LCMM uses in its validation process, the function forwards a maintenance notification to the LCMM domain to enable LCMM to revalidate the LCMM instructions, affected by the static data update (see below the description of the Notify Maintenance function for more information). The function notifies the following static data changes to the LCMM domain: Security Reference Data - update of final maturity date, minimum settlement unit, settlement unit multiple; - creation or logical deletion of deviating settlement unit; - logical deletion. Securities Account Reference Data - update of opening date or closing date; - deletion of a securities account. T2S Dedicated Cash Account Reference Data - update of opening date or closing date; - logical deletion. T2S Dedicated Cash Account Links - logical deletion. External RTGS Accounts - update of opening date or closing date; - logical deletion. The function uses the same mechanism also for an update of a limit. In this case, the function forwards a maintenance notification to the Settlement domain to enable it to check if it must trigger a forced autocollateralization reimbursement. During the night-time processing, the function processes and applies each request immediately. If the requested change may affect the ongoing settlement process, the function creates a revision occurrence for the static data object change and sets the approval status of this revision to Queued. As the function does not apply the change to the current instance of the object, the update does not affect the settlement transactions in the ongoing settlement process. The Static Data Domain revalidates and apply all objects with an approval status Queued (i.e. their approval status is set to Approved ) at the end of the current settlement sequence and before the beginning of the next settlement sequence (or cycle). If the Static Data Domain receives a request outside of a settlement sequence, i.e. between two sequences within the same night-time settlement cycle, between the end of the last sequence of a night-time settlement cycle and the beginning of the first sequence of the following settlement cycle, or after the end of the last night-time settlement cycle and the beginning of the day-light processing), then the function processes and applies the requested change immediately. As a general principle and regardless of the settlement day phase, the static data maintenance processes does not synchronise with any of the concurrent lifecycle management, matching and settlement processes
in order to avoid any performance issues for the processing of settlement instructions. This lack of synchronisation may cause, in some specific cases, technical or business data inconsistencies (e.g. deletion of a securities account linked to pending transactions or open positions). Such inconsistencies shall be avoided a priori by defining ad hoc business constraints. Typically, these business constraints restricts the possibility to perform some specific data changes intra-day, making them possible only as of a future date. The following list provides examples of these static data changes 3 : update of a party securities account relationship; update of a CSD link; update of a tolerance amount; update of a CoSD rule; update of configuration data for auto-collateralisation; update of an eligible counterpart CSD; update of an attribute domain; update of the calendar. By definition, these static data changes may have relevance for the validation of LCMM instructions with an intended settlement date in the future. Therefore, such updates do not result in inconsistencies for the ongoing lifecycle management and settlement processes as they do not access changed data as of a future date. Nevertheless, static data immediately notifies these changes to the LCMM so that the domain can identify and revalidate the relevant individual settlement instructions against static data, i.e. the LCMM instructions, intended for settlement after the date the relevant static data changes becomes valid. The function processes a maintenance using the Four-Eyes principle immediately, regardless of the specific request and the type of static data object involved, but it does not apply the change to the active instance of the static data object until receiving and successfully processing a maintenance approval request. Drawbacks of the approach requested in INC000000162924 As outlined above, the current process is therefore based on the creation of a Queued revision of the object being modified, which is then re-submitted to the internal consistency checks for final approval at the end of the night-time settlement sequence. In other terms, the object is kept in this transient status until the end of the night-time settlement sequence, right after which it can reach its final status (e.g. Completed ). Meanwhile, no other Queued revisions of the same object can be created. The rest of this section speculates around the hypothesis of allowing the creation of multiple transient Queued revisions for the same object within the current design, in order to show the drawbacks this approach would create. If the system allowed two or more revisions to be created and queued for the same object during night-time settlement, this would lead to a number of issues. The main point is that Queued revisions are not completely valid yet, and they can still be rejected at the end of the respective night-time settlement sequence; moreover, the parallel architecture of the T2S application cannot ensure in any way that multiple 3 The exhaustive list of static data changes not allowed intra-day is identified during the detailed specification phase.
static data maintenance instructions would be queued (when reaching T2S) and completed (right after the end of night-time settlement sequence) according to the same order (which may also differ from the chronological order in which the instructions entered the system). Furthermore, it would not be clear how to handle the second (or third, fourth, nth) instruction insisting on the same object during a night-time settlement sequence. One possibility would be to handle all the instructions as concurrent updates of the same object, i.e. each new revision created out of one of the given instructions would use the latest Approved revision as basis. This creates obvious issues, as given several separate instructions, they could all be accepted and queued based on the initial Approved data; however, as the Queued revisions start being approved, each one would overwrite the previous one, which would cause loss of revision data. For example, starting from an object revision 0, three instructions are queued, each with different changes; this creates three revisions 1a, 1b and 1c each of which does not contain the changes that the others do. 1a is approved, and becomes the new Approved revision; same for 1b and finally for 1c. In the end the Approved revision only includes the changes related to 1c, and loses the ones related to 1a and 1b for no apparent reason on user side. Moreover, since the order of processing is not predetermined, the user would not be able to know which changes are implemented and which are lost; finally, no all-or-nothing logic would be applied, so some of the changes may be rejected and, again, the user would not be able to know which ones. These drawbacks are explored in detail in the examples below. It should be noted that this approach is the one that results from applying the process described in the functional specifications, with the only difference being the assumption that the system should allow multiple queued instances for the same object (as requested by Clearstream). Example 1 Multiple updates of a Security during the same night-time settlement sequence. The following security: ISIN Other Attributes MSA-X Intraday Restrictions Revision Status ISIN123 Issue Date, CFI, etc. MSA-01-1 Approved is maintained during a given night-time settlement sequence by setting up an intraday restriction IR1 on it. This results in the creation of a new revision of the security with status Queued : ISIN Other Attributes MSA-X Intraday Restrictions Revision Status ISIN123 Issue Date, CFI, etc. MSA-01-1 Approved ISIN123 Issue Date, CFI, etc. MSA-01 IR1 2 Queued 4 The same security is maintained again during the same night-settlement sequence by updating the value of a given market-specific attribute MSA-X from MSA-01 to MSA-02. This results in the creation of a further 4 In all the examples, red font is used to highlight the changes between the starting revision and the newly created revision.
revision of the security with status Approved (as updates of securities market-specific attribute values are not queued, according to table 144 of UDFS v.2.0): ISIN Other Attributes MSA-X Intraday Restrictions Revision Status ISIN123 Issue Date, CFI, etc. MSA-01-1 Approved ISIN123 Issue Date, CFI, etc. MSA-01 IR1 2 Queued ISIN123 Issue Date, CFI, etc. MSA-02-3 Approved Right after the end of the night-settlement sequence, the queued static data maintenance instruction is resumed, in order to complete the processing started while the night-time settlement sequence was running. On this basis, revision 2 is approved, resulting in the creation of new revision (4) of the Security with status Approved : ISIN Other Attributes MSA-X Intraday Restrictions Revision Status ISIN123 Issue Date, CFI, etc. MSA-01-1 Approved ISIN123 Issue Date, CFI, etc. MSA-01 IR1 2 Queued ISIN123 Issue Date, CFI, etc. MSA-02-3 Approved ISIN123 Issue Date, CFI, etc. MSA-01 IR1 4 Approved So, after the end of the processing of the queued static data maintenance instruction, the last approved revision of the maintained security only contains the changes included in the last approved update, i.e. only the update related to the intraday restriction IR1 (which was the first to be submitted by the user) and not the update of the value related to the market-specific attribute MSA-X, which remained active only from the moment it was approved (during the night-time settlement sequence) and the moment the following queued change was approved (after the end of the night-time settlement sequence). Besides this undesired effect from a pure SDMG viewpoint (and its obvious consequences for all the other T2S processes making use of market-specific attributes), the described behaviour would also have broader implications for other T2S processes and therefore for the user. In this example, for instance, when querying for the history of data changes applied on security ISIN123 (either in A2A mode via reda.009 or in U2A mode through the Data Changes screen) the user would see all the above revisions tracked as changes, while they do not correspond to the actual changes that were included in the Static Data maintenance instructions processed by T2S. For example, for the last object revision the history of data changes would report two changes (i.e. the update of MSA-X from MSA-02 to MSA-01 plus the setup of the intraday restriction IR1 ) when such a Static Data maintenance instruction was never submitted by the user (in fact, the corresponding submitted request contained the setup of the intraday restriction IR1 only). This would obviously create issues on the user side when trying to reconcile the Static Data maintenance instructions submitted to T2S and the resulting history of data changes.
Example 2 Multiple updates of a Security during the real-time settlement sequence. The following security: ISIN Other Attributes MSA-X SUM Intraday Restrictions Revision Status ISIN123 Issue Date, CFI, etc. MSA-01 1.25-1 Approved is maintained at 10:30 am by updating its settlement unit multiple from 1.25 to 1.75 and the value of the market-specific attribute MSA-X from MSA-01 to MSA-02. This results in the creation of a new revision of the security with status Queued : ISIN Other Attributes MSA-X SUM Intraday Restrictions Revision Status ISIN123 Issue Date, CFI, etc. MSA-01 1.25-1 Approved ISIN123 Issue Date, CFI, etc. MSA-02 1.75-2 Queued The same security is maintained again at 11:45 am by setting up an intraday restriction IR1 on it and by updating the value of the market-specific attribute MSA-X from MSA-01 to MSA-03. This results in the creation of a further revision of the security with status Approved : ISIN Other Attributes MSA-X SUM Intraday Restrictions Revision Status ISIN123 Issue Date, CFI, etc. MSA-01 1.25-1 Approved ISIN123 Issue Date, CFI, etc. MSA-02 1.75-2 Queued ISIN123 Issue Date, CFI, etc. MSA-03 1.25 IR1 3 Approved The same security is maintained again at 3:20 pm by updating again the settlement unit multiple from 1.25 to 2.25. This results in the creation of a further revision of the security with status Queued : ISIN Other Attributes MSA-X SUM Intraday Restrictions Revision Status ISIN123 Issue Date, CFI, etc. MSA-01 1.25-1 Approved ISIN123 Issue Date, CFI, etc. MSA-02 1.75-2 Queued ISIN123 Issue Date, CFI, etc. MSA-03 1.25 IR1 3 Approved ISIN123 Issue Date, CFI, etc. MSA-01 2.25-4 Queued During the EoD phase, the two queued static data maintenance instructions are resumed, in order to complete the processing started the real-time settlement phase. Let us assume that the two pending instructions are resumed and processed following the same order according to which they were processed during the real-time settlement phase. In
this case, revision 2 will be approved in the first place, resulting in the creation of new revision (5) of the Security with status Approved : ISIN Other Attributes MSA-X SUM Intraday Restrictions Revision Status ISIN123 Issue Date, CFI, etc. MSA-01 1.25-1 Approved ISIN123 Issue Date, CFI, etc. MSA-02 1.75-2 Queued ISIN123 Issue Date, CFI, etc. MSA-03 1.25 IR1 3 Approved ISIN123 Issue Date, CFI, etc. MSA-01 2.25-4 Queued ISIN123 Issue Date, CFI, etc. MSA-02 1.75-5 Approved Then, revision 4 will be approved, resulting in the creation of the new revision (6) of the Security with status Approved : ISIN Other Attributes MSA-X SUM Intraday Restrictions Revision Status ISIN123 Issue Date, CFI, etc. MSA-01 1.25-1 Approved ISIN123 Issue Date, CFI, etc. MSA-02 1.75-2 Queued ISIN123 Issue Date, CFI, etc. MSA-03 1.25 IR1 3 Approved ISIN123 Issue Date, CFI, etc. MSA-01 2.25-4 Queued ISIN123 Issue Date, CFI, etc. MSA-02 1.75-5 Approved ISIN123 Issue Date, CFI, etc. MSA-01 2.25-6 Approved So, after the end of the processing of all the queued static data maintenance instruction, the last approved revision of the maintained security only contains the changes included in the last approved update, i.e. only the update of the value related to the settlement unit multiple (and not the intraday restriction IR1 or any updates of the value of the marketspecific attribute MSA-X). As highlighted in the previous example, the undesired effects stemming from the described behaviour would not necessarily be limited to SDMG. In this case, for instance, an intraday restriction is applied to Security ISIN123 at 11:45 am, which implies SETT receives an immediate Static Data update notification for this. This intraday restriction remains in SDMG until the End-of-Day period, when it is overwritten as a side effect of the approval of the Static Data change queued at 3:20 pm (see revision 5), while in this case SETT does not receive any notification (because in fact there was no actual request of removal of the intraday restriction by the user). This means that the new business day will start with an intraday restriction IR1 that still exists in SETT while it does not exist anymore in SDMG. Consequently: there will be no way to remove said intraday restriction via the standard SDMG functionality (simply because it does not exist anymore in the SDMG data base) and
the user may setup another intraday restriction of the same type and overlapping with IR1, which would result in unpredictable consequences when this Static Data update is notified to SETT. In case the processing of the queued instructions would have followed the reverse order, this would have been the resulting sequence of revisions: ISIN Other Attributes MSA-X SUM Intraday Restrictions Revision Status ISIN123 Issue Date, CFI, etc. MSA-01 1.25-1 Approved ISIN123 Issue Date, CFI, etc. MSA-02 1.75-2 Queued ISIN123 Issue Date, CFI, etc. MSA-03 1.25 IR1 3 Approved ISIN123 Issue Date, CFI, etc. MSA-01 2.25-4 Queued ISIN123 Issue Date, CFI, etc. MSA-01 2.25-5 Approved ISIN123 Issue Date, CFI, etc. MSA-02 1.75-6 Approved So, in this case after the end of the processing of all the queued static data maintenance instructions, the values for the settlement unit multiple (1.75) and for the market-specific attribute MSA-X ( MSA-02 ) would not be the last one submitted by the user (2.25 and MSA-03, respectively) and the intraday restriction IR1 would be lost (as in the previous case). Obviously, the same implications described above for the other T2S processes are valid in this case as well. Example 3 Multiple updates and deletion of a Limit during the same night-time settlement sequence. The following limit: DCA CMB Valid From Value Revision Deletion 5 Status DCA123 CMB1 22-Jun-2015 0 1 Active Approved is maintained during a given night-time settlement sequence by updating its value from 0 to 100. This results in the creation of a new revision of the security with status Queued : DCA CMB Valid From Value Revision Deletion Status DCA123 CMB1 22-Jun-2015 0 1 Active Approved DCA123 CMB1 22-Jun-2015 100 2 Active Queued The same limit is deleted during the same night-settlement sequence. This results in the creation of a further revision of the security with status Queued : 5 This attribute is not shown in the previous examples are not relevant in those cases.
DCA CMB Valid From Value Revision Deletion Status DCA123 CMB1 22-Jun-2015 0 1 Active Approved DCA123 CMB1 22-Jun-2015 100 2 Active Queued DCA123 CMB1 22-Jun-2015 0 3 Deleted Queued The same limit is maintained again during the same night-settlement sequence by updating its value from 0 to 150. This results in the creation of a further revision of the security with status Queued : DCA CMB Valid From Value Revision Deletion Status DCA123 CMB1 22-Jun-2015 0 1 Active Approved DCA123 CMB1 22-Jun-2015 100 2 Active Queued DCA123 CMB1 22-Jun-2015 0 3 Deleted Queued DCA123 CMB1 22-Jun-2015 150 4 Active Queued Right after the end of the night-settlement sequence, the three queued static data maintenance instructions are resumed, in order to complete the processing started while the night-time settlement sequence was running. Let us assume that the three pending instructions are resumed and processed following the same order according to which they were processed during the night-time settlement sequence. In this case, revision 2 will be approved in the first place, resulting in the creation of new revision (5) of the limit with status Approved : DCA CMB Valid From Value Revision Deletion Status DCA123 CMB1 22-Jun-2015 0 1 Active Approved DCA123 CMB1 22-Jun-2015 100 2 Active Queued DCA123 CMB1 22-Jun-2015 0 3 Deleted Queued DCA123 CMB1 22-Jun-2015 150 4 Active Queued DCA123 CMB1 22-Jun-2015 100 5 Active Approved Then, revision 4 will be approved, resulting in the deletion of the limit, i.e. the creation of a new revision (6) with status Approved and deletion status Deleted : DCA CMB Valid From Value Revision Deletion Status DCA123 CMB1 22-Jun-2015 0 1 Active Approved DCA123 CMB1 22-Jun-2015 100 2 Active Queued
DCA123 CMB1 22-Jun-2015 0 3 Deleted Queued DCA123 CMB1 22-Jun-2015 150 4 Active Queued DCA123 CMB1 22-Jun-2015 100 5 Active Approved DCA123 CMB1 22-Jun-2015 0 6 Deleted Approved Finally, revision 5 will be approved, resulting in the creation of the new revision (7) of the limit with status Approved : DCA CMB Valid From Value Revision Deletion Status DCA123 CMB1 22-Jun-2015 0 1 Active Approved DCA123 CMB1 22-Jun-2015 100 2 Active Queued DCA123 CMB1 22-Jun-2015 0 3 Deleted Queued DCA123 CMB1 22-Jun-2015 150 4 Active Queued DCA123 CMB1 22-Jun-2015 100 5 Active Approved DCA123 CMB1 22-Jun-2015 0 6 Deleted Approved DCA123 CMB1 22-Jun-2015 150 7 Active Approved So, after the end of the processing of all the queued static data maintenance instruction the last approved revision of the maintained limit contains the value 150 despite the fact the same limit was successfully deleted just before. As illustrated in the previous examples, the final result depends anyway on the order according to which the queued instructions are processed after the end of the night-time settlement sequence. In this case, the three possible final results are: a limit with value 100, a limit with value 150, a deleted limit. As mentioned in the two previous examples, other T2S processes besides SDMG may be negatively influenced by the described behaviour. Similarly to what is shown for the intraday restriction of example 2, in this case SETT would receive three Static Data update notifications on the same limit: one related to the update of the limit to 100, the second concerning the deletion of the same limit, the third related to the update of the same limit (that was just deleted) to 150. The third notification, being inconsistent with the previous ones, may result in unpredictable consequences for SETT. Example 4 Multiple updates of a Securities Account during the same night-time settlement sequence. The following securities account: Account Number Other Attributes Opening Date Closing Date Revision Status
SAC123 Type, Currency, etc. 01/03/2016-1 Approved is maintained during a given night-time settlement sequence by postponing its opening date by five days. This results in the creation of a new revision of the securities account with status Queued : Account Number Other Attributes Opening Date Closing Date Revision Status SAC123 Type, Currency, etc. 01/03/2016-1 Approved SAC123 Type, Currency, etc. 06/03/2016-2 Queued The same securities account is maintained again during the same night-settlement sequence by setting the value of its closing day to 31/12/2017. This results in the creation of a further revision of the securities account with status Queued : Account Number Other Attributes Opening Date Closing Date Revision Status SAC123 Type, Currency, etc. 01/03/2016-1 Approved SAC123 Type, Currency, etc. 06/03/2016-2 Queued SAC123 Type, Currency, etc. 01/03/2016 31/12/2017 3 Queued Right after the end of the night-settlement sequence, the queued static data maintenance instructions are resumed, in order to complete the processing started while the night-time settlement sequence was running. Let us assume that the two pending instructions are resumed and processed following the same order according to which they were processed during the night-time settlement sequence. In this case, revision 2 will be approved in the first place, resulting in the creation of a new revision (4) of the securities account with status Approved : Account Number Other Attributes Opening Date Closing Date Revision Status SAC123 Type, Currency, etc. 01/03/2016-1 Approved SAC123 Type, Currency, etc. 06/03/2016-2 Queued SAC123 Type, Currency, etc. 01/03/2016 31/12/2017 3 Queued SAC123 Type, Currency, etc. 06/03/2016-4 Approved Then, revision 3 will be approved, resulting in the creation of a new revision (5) of the securities account with status Approved : Account Number Other Attributes Opening Date Closing Date Revision Status
SAC123 Type, Currency, etc. 01/03/2016-1 Approved SAC123 Type, Currency, etc. 06/03/2016-2 Queued SAC123 Type, Currency, etc. 01/03/2016 31/12/2017 3 Queued SAC123 Type, Currency, etc. 06/03/2016-4 Approved SAC123 Type, Currency, etc. 01/03/2016 31/12/2017 5 Approved So, after the end of the processing of the queued static data maintenance instructions, the last approved revision of the maintained securities account only contains the change included in the last approved update, i.e. only the update related to the closing date and not the update of the value related to the opening date of the securities account. In fact, the update of the opening date value remained active only from the moment it was approved and the latter update was approved. Also in this case, besides this undesired effect from a pure SDMG viewpoint, the described behaviour propagates its implications to other T2S processes and therefore to the user. In this example, both Static Data updates are subject to notification to LCMM for the revalidation of settlement instructions. On this basis, the first update (revision 4) triggers the cancellation of all CSD participant settlement instructions insisting on SAC123 and having ISD falling between 01/03/2016 and 06/03/2016, whereas the second update (revision 5) triggers the cancellation of all CSD participant settlement instructions insisting on SAC123 and having ISD > 31/12/2017. So, in terms of revalidation LCMM behaves as expected by the user. However, the validation process will not, as LCMM will reject (as expected by the user) CSD participant settlement instructions insisting on SAC123 and having an ISD falling between 01/03/2016 and 06/03/2016 only in the timeframe between the approval of revision 4 and 5, whereas it will start accepting them again (unexpectedly, from a user viewpoint) right after the approval of revision 5. Furthermore, as SDMG and LCMM processes are asynchronous, it may also happen that the revalidation process triggered by revision 4 is actually performed by LCMM only after revision 5 has already been approved, which means the revalidation process will miss the Static Data update related to revision 4 and therefore it will never cancel the CSD participant settlement instructions insisting on SAC123 and having ISD falling between 01/03/2016 and 06/03/2016. The second possibility (being completely hypothetical, as it does not correspond to the way object revisions are currently managed according the specifications) would be to have a sequential chain of instructions each of which incorporates the changes input by the previous one. This approach also has issues, which are summarized in the following example: - During a night-time settlement sequence, at t 0, user A sends a maintenance instruction to modify Securities Account SAC001. This creates a first Queued revision SAC001-01. - Before the end of the night-time settlement sequence, at t 1 (with t 1 > t 0 ), user B sends a maintenance instruction on the same Securities Account SAC001. In this hypothetical example, this would create a second Queued revision SAC001-02, which also includes the changes from the first maintenance instruction. - At the end of the night-time settlement sequence, both maintenance instructions are reprocessed to verify their persisting compliance to the business validation rules.
- Revision SAC001-01 fails a business validation and is rejected. - This also leads to rejecting revision SAC001-02, which may contain valid changes in itself, but also contains the changes input in SAC001-01. In other words User B sees a change which is initially accepted, and subsequently rejected due to the prior actions of another independent user. - To come back to the issue of instruction ordering, even if the offending change is the one directly linked to SAC001-01, SAC001-02 could be processed before. This could lead to SAC001-02 being approved, and SAC001-01 subsequently being rejected. Since SAC001-02 also includes the changes related to SAC001-01, this would lead to an invalid revision. These examples highlight how the handling of multiple queued Static Data maintenance instructions on the same object during night-time settlement does not allow ensuring the requested changes are executed following an all-or-nothing principle and the user would be able to know the actual changes successfully implemented only by the end of the processing taking process after the end of the night-time settlement sequence. Conclusions 1. We believe the current behaviour of the software is in line with the user requirements (with specific reference to the update constraints depicted in T2S.16.310, stipulating that When a T2S system user or T2S process selects an occurrence for editing, T2S shall lock the occurrence so that a second T2S system user or T2S process cannot access it for update ) and with the functional design (in particular with the design option retained since GFS v.3.0 for the processing of static data maintenance requests during the night-time phase). 2. Modifying the software as requested in INC162924, i.e. by removing the check ensuring that a static data object in Queued status cannot be further updated, is not a viable option, as it would create a number of serious drawbacks (e.g. like the ones described above). 3. As to the way forward, we only see two possible options: 3.1. To leave the design as is and to introduce via Change Request (to be issued by the Eurosystem) a clarification in the UDFS and in the UHB, should you deem this useful. 3.2. To revert back to the design option that was in place up to GFS v.2.0 or to identify any other option (covering all the possible scenarios of multiple updates of the same static data object within the same night-time settlement sequence, or within the same settlement day in the specific case of Securities), which would require a Change Request (to be issued by Clearstream) and, when eventually approved, a change in the T2S application.