A A Technical Framework

AA Technical Framework

Temenos University - August 2012

1

AA Technical Framework

Temenos University - August 2012

2

AA Technical Framework

Welcome to this AA Technical Framework session. Our learning objectives are: - Learn how to Proof and Publish an AA Product with Product Manager - Understand how Products’ changes can be monitored and controlled through AA Product Tracker tool - Learn how to use the AA Simulation Engine - Understand the basics of Rules Engine in Toolbox

Temenos University - August 2012

3

AA Technical Framework

Temenos University - August 2012

4

AA Technical Framework

The first topic we are going to cover is the Proof & Publish process for new AA Products. This concept was firstly introduced during the AA Introduction (For AA Lending) course and we are now going to see, in detail, which applications are involved in this process and how they work. Before we proceed with this, though, it is worth having a brief review of the concepts of Proofing and Publishing. As we know, once a product has been designed, it should be tested through quality checks and only once it has passed them, it will be ready to be placed in the market.

Temenos University - August 2012

5

AA Technical Framework

A Product in AA goes through three processes – Product designing, proofing and publishing. Designing is the Process of creating Products and attaching Product Conditions to their Properties and it is done using the T24 Product Builder. During the design stage, the designers make use of available components to design and their actions will have no effect on the live products When a product is designed, it has to undergo Proofing process in order to make it available to operational staff. Proofing validates that the Product has been configured correctly without errors, and is ready for release. Proofing is the process that checks whether the product is in sync with its hierarchy such as Parent and or the associated Product Group. Once a product is proofed, it has to be published. Publishing is the process by which a Product is put into Product Catalog. Once a product is published into Product Catalog, it is available for sale. When a parent Product is proofed and published, these functions are performed down the line to all the children Products under it. In this case it is not necessary to individually proof and publish the child Products. New Arrangements can be created for a product published into Product Catalog.

Temenos University - August 2012

6

AA Technical Framework

To sum up, Proofing: -

Expands product definition to include inherited property definitions Ensures that a currency condition exists for each allowed currency for product Ensures all mandatory properties have been included Ensures that a condition exists for each of the afore-mentioned property Cross-validates product conditions to ensure consistency and avoid conflicts

Temenos University - August 2012

7

AA Technical Framework

The above diagram defines the relationship between proof and publish. As you have seen in the AA Product Builder course, the Product Builder allows you to create Products with their Properties and Conditions. The next stage is Proofing. At the proofing stage, we need to set the available date of the product. This will allow you to enter the product into the catalog before making it available for sales. Proofing then ensures that the product has been configured correctly and is ready for release. Proofing includes for example checking whether all mandatory properties have been given conditions, that there are no conflicts between those conditions, and any other errors that would prevent the product from being published. Any errors generated can be fixed by going back to the Product Builder, and then reproofing the product. When the product is published, it is entered into the Product Catalog, which is the tool used to actually create Arrangements. Once published, products can be modified at any time. Modification is done in the Product Designer, using the same method as for creation. Modifications will only appear in the Product Catalog once the proofing & publishing process has been repeated.

Temenos University - August 2012

8

AA Technical Framework

AA.PRODUCT.MANAGER is the application used to Proof and Publish new products or amended ones. Specifically, this application will allow administrators to: • Select the product they wish to operate on through the record ID (AA.PRODUCT.MANAGERS record IDs are the same as products’ IDs) • The action on the Product - Like PROOF, PUBLISH etc • Available Date for the product • Expiry date of the product An action can be performed only through Product Manager and on any level of a product family. As previously anticipated, when a proofing or publishing action is performed on a product the same action will automatically take place on the child products too. Publishing and Proofing will perform processing from parent down to all children. The hierarchy will be resolved using the published product definitions. The Proofing and Publishing process will result in the creation of product specific property condition records The most important fields on the AA.PRODUCT.MANAGER application are: 1. 2.

3. 4. 5. 6. 7.

8. 9.

10.

GB.DESCRIPTION – Contains a meaningful description of the current process ACTION – Defines the action that is being performed on this product. The possible options are: 1. PROOF - The product has been designed and it is ready to be proofed. This is the first step in any publishing process and, as we know, it performs the following tasks: • Expands the product definition to include the inherited property definitions from the published parent product • Ensures that the resolved product definition includes all mandatory properties identified in the Product Group definition. • Ensures that conditions exist for each property condition linked to a product. • Ensures that a currency condition exists for each allowed currency for the product. • Cross-validates product property conditions to ensure consistency and avoid conflicting values Product proofing will use the current Product Designer definitions for the product to perform the proofing validation. The proofing process will return any errors found in the validation process (updated in PRODUCT.ERRORS field) and these must be fixed before the product can be published. 2. CANCEL.PROOF – After a successful proofing process or a partially successful one, if the user wishes to cancel the proofing process, he may choose this option which would bring the product back to the stage before proofing process was attempted. Cancel proof involves deleting the PRF records which may have been updated (we’ll learn about these records in the coming slides). 3. PUBLISH – After the product has been successfully proofed, then the next step is to update this product to catalog and make it available for sale to the customers. The process of moving files from PROOF to CATALOG is achieved by this option. When there are proofing errors, the product cannot be published. Also the status of the product in AA.PRODUCT file should be 'PROOFED' to attempt this option. The rules which govern the proofing process(with respect to hierarchy) apply to publishing as well. AVAILABLE.DATE – This field is mandatory and contains the date from which the current product is available. The system starts looking for valid conditions for all properties from this date onwards EXPIRY.DATE – This optional field indicates the date from which this product ceases to exist. It only means that new arrangements may not be input from this date on for this product. PRODUCT.ERROR – If any errors arise during the Proofing and Publishing process, they are updated in this multi-value, system-maintained field. The administrator in charge of the publishing process should monitor these errors and take corrective steps, in case. Errors will be cleared when the user has fixed the issues which caused them. SUGGESTION – This field suggests the user on what should be done if an error is occured. It is an multi-value set and for each error occurred in PRODUCT.ERROR, corresponding SUGGESTION is given to rectify the error PRODUCT.VERSION – Indicates the current ‘version’ of the product – meaning an incremental numeric value which is updated by the system anytime an action is performed on the product. This field is no-input and it is automatically incremented by 0.1 for every action that the user performs on the product. It starts with 0 and, after the first proofing process, is update to 0.1. The following proofing/Cancel proofing action will increment the version number by 0.1. When the product is successfully published, it moves to the next whole number. In this case, when the product is published successfully, the version would move to 1. Further processing on this product would update version to 1.1, 1.2 and 2 after successful publishing etc PROCESS.METHOD – This field allows to select the processing method for Actions like Proofing, Publishing etc. Valid options are ONLINE or SERVICE: ONLINE means that the product will be proofed/published online while SERVICE means that actions on the product will be carried out as a service PROCESS.STATUS – This system-updated field indicates processing status of the action selected in the ACTION field. Valid options are: • COMPLETED SUCCESSFULLY – This process status means that the current action has been completed successfully on a Product without errors • COMPLETED WITH ERRORS – Product’s action has been completed with errors. This requires a manual user intervention to clear these errors • PROCESSING... – This status is applied when proofing/publishing is done through the ‘Service’ method. It indicates that the BNK/AA.PUBLISH.SERVICE service is processing the record. Please note that, if the service is not run at all, the system would also show this status RELATED.PRODUCT – This field indicates the list of related products that is proofed/published along with the ID product – e.g. children products which get proofed/published when a parent product does. This is a NOINPUT system maintained field.

Now that we have presented the AA.PRODUCT.MANAGER application, let us see how it is used to Proof and Publish Products

Temenos University - August 2012

9

AA Technical Framework

Temenos University - August 2012

10

AA Technical Framework

Proofing can be executed on a product using the AA.PRODUCT.MANAGER application or through one of its versions. In this example, we are going to use the AA.PRODUCT.MANAGER,AA version which is available on the AA.PRODUCT.DESIGNER-PRODUCTS composite screen accessible from the MB Admin Menu. The path to this composite screen is Admin Menu > Product Builder > Products 1.

Once you have accessed this composite screen, select the Product Line, the Product Group and, finally, the Product that you wish to Proof. From the Product Builder screen, select the ‘Manage’ icon just beside the Product you have chosen (NEGOTIABLE.LOAN record under the label ‘Fully Negotiable Loan’, in this example)

2.

Action should be set to Proof

3.

Available Date field should be set to the date on which the Product becomes available for sale

4.

‘Online/Service’ is a label for the field PROCESS.METHOD in this version, so the option ONLINE should be selected in this case

5.

Once required fields are set, the AA.PRODUCT.MANAGER record should be validated and committed.

6.

On committing the record, a context enquiry called AA.PUBLISH.SERVICE.MONITOR (based on the AA.PRODUCT.MANAGER application) will pop up and show the output of the Proofing action.

7.

Errors in proofing will be displayed here and, if no error is encountered, the process status will be set to ‘Completed Successfully’

8.

Once Proofing is completed, the Product Version field will be updated on the AA.PRODUCT.MANAGER record (in this case, its value is changed from ‘2’ to ‘2.1’ as expected)

Temenos University - August 2012

11

AA Technical Framework

Once successfully Proofed the product can then be Published. As we know, AA.PRODUCT.MANAGER application and its versions are also used to Publish products. And, again, for this example we are going to use the AA.PRODUCT.MANAGER,AA version available in R12 Model Bank under Admin Menu > Product Builder > Products 1. We should identify the correct Product Line and Product Group, select the Product we are interested in publishing (NEGOTIABLE.LOAN) and then click again on the ‘Manage’ icon beside it 2. Once the record is opened, we should change the Action field to PUBLISH, check that the Process Method is set to ONLINE and that the other fields are completed correctly 3. On committing the record, again, the AA.PUBLISH.SERVICE.MONITOR enquiry output will pop up & define whether the Publishing process has generated any error or was successfully completed. Please notice that an error will be thrown if we try to publish a record before having proofed it correctly. 4. Once Publishing is completed, PRODUCT.VERSION field will be automatically updated in the AA.PRODUCT.MANAGER record to the next available integer (in this case, its value changes from 2.1 to 3)

Temenos University - August 2012

12

AA Technical Framework

Temenos University - August 2012

13

AA Technical Framework

BNK/AA.PUBLISH.SERVICE is a service in charge of processing PROOF, PUBLISH and CANCEL PROOF actions when the Process Method field is set to SERVICE in AA.PRODUCT.MANAGER. Services, as we know, are multi-threaded background processes in T24 and they are started, stopped and configured through the TSA.SERVICE application – these background processes are run by a set of programs called T24 Service Agents (abbreviated as TSAs) and controlled by a ‘master’ service called T24 Service Manager (TSM). In case you wish to gather further information on services, you should review the Close of Business and Services course, which is a pre-requisite for the current session. If we wish to Proof, Cancel Proof or Publish a Product via Service method, we must activate the BNK/AA.PUBLISH.SERVICE first. This can be done either through TSA.SERVICE directly or using a version of this application. In the R12 Model Bank menu, a zero-authoriser version called TSA.SERVICE,MANAGE is available under Admin Menu > System Administration > TSA Service Control. Through this path, we can access the TSS.LIST composite screen, which presents us with a query of active services on the top left-hand side frame, a list of T24 Service Agents with their current status on the top right-hand side frame and TSA.SERVICE,MANAGE version on the bottom frame. On this latter screen, we should input the id of our BNK/AA.PUBLISH.SERVICE and click on the ‘Edit’ button. Once we have accessed the record, the SERVICE.CONTROL field should be set to AUTO or START to initiate the service (in this specific case, the two options are equivalent because BNK/AA.PUBLISH.SERVICE is an Auto Service, which means that – once it is started – it will keep on running in the background until manually stopped even after if has processed all queuing records). Please note that, if we want our service to run, we must make sure that also TSM record in TSA.SERVICE is activated. In this scenario, we are assuming that TSM is already running in the system, in fact we can see it amongst the list of active services on the TSS.LIST enquiry output (top frame on the left). In case TSM is stopped, though, we can start it in the same way we start any other service.

Temenos University - August 2012

14

AA Technical Framework

Once, TSM and BNK/AA.PUBLISH.SERVICE have been activated in TSA.SERVICE, it is necessary to start the required T24 Service Agents from jshell – without this step, activated services cannot start their processing. You can start TSAs in two ways – 1.

In a Background (Phantom) mode, by using the command START.TSM on jshell – This command will trigger the first available T24 Service Agent ( in this case, tSA 1) which start automatically running the TSM service (i.e. it will start acting as a ‘manager’ for other services). What the manager does is to check TSA.SERVICE and TSA.WORKLOAD.PROFILE applications to find out which services should be initiated (those whose SERVICE.CONTROL field in TSA.SERVICE has been set to AUTO or START) and how many resources (tSAs) should be assigned to each of these services. If we are running TSM in the background, the agent acting as service manager will automatically start the required agents, assign them to a specific job and monitor them constantly.

2.

In a Foreground (Interactive) mode, by using the command START.TSM –DEBUG on jshell – START.TSM –DEBUG will also ‘wake up’ an available tSA and assign it to the TSM service but this program will be executed in an interactive way. This imply that the manager will read TSA.SERVICE and TSA.WORKLOAD.PROFILE applications to define which tSAs should be started for which service but it will prompt the user to manually start them and monitor them, instead of initiating/controlling them automatically. In this case, the user in control will have to open a new jshell session for each of the tSAs to be started and then initiate them as shown.

In a real-life situation where T24 is stable and COB processes are stable, TSM and the other services will normally run in a Phantom mode while the Interactive way is ideal for testing new processes and troubleshooting.

Temenos University - August 2012

15

AA Technical Framework

Once we have started BNK/AA.PUBLISH.SERVICE, we can now use the usual AA.PRODUCT.MANAGER version on the product Builder screen to Proof a product using ‘Service’ as a Process Method. For this example, we are going to use the COMMITMENT.SAVINGS product (labelled as ‘Commitment Savings Plan’ on the Product Builder menu). 1. COMMITMENT.SAVINGS record is accessed as usual through the ‘Manage’ icon on the Product Builder screen and accessed in an ‘Edit’ mode 2. Fields on the record should be filled in as usual – in this case we should ensure, in particular, that Action is set to PROOF and that the Process Method chosen is SERVICE 3. On committing the AA.PRODUCT.MANAGER record, the usual AA.PUBLISH.SERVICE.MONITOR enquiry (labelled ‘Status Monitor’) will pop up and show the output of the Proofing action – as the selected Process Method is SERVICE it may take a few moments for our Action to be processed and, consequently, the initial Process Status shown on the Monitor will be ‘PROCESSING…’. Please note that, for some reason, the BNK/AA.PUBLISH.SERVICE is offline, the Process Status displayed will be also ‘PROCESSING…’ but won’t change to ‘Completed Successfully’. 4. Also in this case the Status Monitor screen will show any errors incurred, in case, while the process status will be set to ‘Completed Successfully’ if proofing runs smoothly. 5. Once Proofing is completed, the Product Version field will be updated on the AA.PRODUCT.MANAGER record

Temenos University - August 2012

16

AA Technical Framework

A similar process is used to Publish the Product. Please remember that BNK/AA.PUBLISH.SERVICE is still running and that this same service is in charge of both proofing and publishing Products when the ‘Service’ Process Method is selected (and also of Cancel Proof, in case). 1. COMMITMENT.SAVINGS record is edited as usual with AA.PRODUCT.MANAGER: Action field is set to PUBLISH and that the Process Method chosen is SERVICE 2. On committing the AA.PRODUCT.MANAGER record, again, the Status Monitor screen will pop up and show initially a ‘PROCESSING…’. Status followed by a ‘Completed Successfully’ status if publishing did not encountered errors or, else, ‘Completed in Error’ (details of the issues raised are also visible on the enquiry output, in this case). 3. As usual, once Publishing is completed, the Product Version field will be updated on the AA.PRODUCT.MANAGER record In all previous examples, we were taking action on already existing products. Nevertheless, the proofing and publishing mechanism is also used to validate and publish for the first time a brand new product. In this latter case, after the first successful publishing, the product will be automatically included under the Product Catalog that you find under User Menu > Product Catalog.

Temenos University - August 2012

17

AA Technical Framework

Temenos University - August 2012

18

AA Technical Framework

The AA module offers a set of applications to monitor the Proof and Publish processes. These are – 1. AA.PRODUCT.PROOF – automatically updated by the system when a product is proofed 2. AA.PRD.PRF. – keeps track of changes taking place on product conditions during proofing 3. AA.PRODUCT.CATALOG – automatically updated by the system when a product is published to the Catalog 4. AA.PRD.CAT. – keeps track of new product conditions in a product when published Let us now try to see how they work with an example.

Temenos University - August 2012

19

AA Technical Framework

1. Once the product designed in AA.PRODUCT.DESIGNER has been proofed, the proofed record will be written to AA.PRODUCT.PROOF. This file is read only. On publishing, all records for this product will be removed. IDs in AA.PRODUCT.PROOF follow the structure – <Effective Date> 2. The final designed product information is updated in this application 3. It holds data that looks similar to that of the product designer –both applications share the same ID structure and most fields: a Short and Full description of the product (GB.DESCRIPTION and FULL.DESC fields), information regarding Product Group (PRODUCT.GROUP), Parent Product (PARENT.PRODUCT), Currencies allowed (CURRENCY) and a list of properties which are part of the product (PROPERTY) together with a pointer to a list of conditions for those properties (PRD.PROPERTY) In this example the product used is MORTGAGE.OFFER.

Temenos University - August 2012

20

AA Technical Framework

1. The proofed product conditions are updated in a set of applications prefixed with AA.PRD.PRF.. 2. When a product is proofed, a copy of the product conditions attached in the product is picked and a record in the AA.PRD.PRF. application is created for each appropriate property within the product. In this example, the proofed product MORTGAGE.OFFER contains the NEWARRFEE property, which is derived by the CHARGE property class. Therefore, proofed product conditions for NEWARRFEE in MORTAGE.OFFER will be updated in an application called AA.PRD.PRF.CHARGE (the CHARGE property class is used to define charges and can be added to PAYMENT SCHEDULE property class for defining scheduled charges. To define charges related to an activity, instead, this class can be used in connection with the ACTIVITY.CHARGE property class). 3. The record in AA.PRD.PRF.CHARGE regarding the proofed NEWARRFEE property in MORTGAGE.OFFER contains a brief description of the property and list of its features. The ID structure of a record within AA.PRD.PRF. applications is – ---<Effective Period – only if specified>- . The ID structure is also detailed in the multi-value field ID.COMP. In this specific example, the ID of the AA.PRD.PRF.CHARGE record will be – MORTGAGE.OFFER-NEWARRFEE-USD--20120126

Temenos University - August 2012

21

AA Technical Framework

A new record in an AA.PRD.PRF. application is created for each of the properties of the proofed PRODUCT. Here’s another example with the PRESENTATION property – this does not belong to a currency-based property class and, therefore, currency is not included in the AA.PRD.PRF.ACTIVITY.PRESENTATION record ID, which in this case is MORTGAGE.OFFER-PRESENTATION---20120126

Temenos University - August 2012

22

AA Technical Framework

1. When a product is published, the record from AA.PRODUCT.PROOF is deleted and AA.PRODUCT.CATALOG is updated 2. It holds the final published product 3. AA.PRODUCT.PROOF records store data similar to the product designer’s

Temenos University - August 2012

23

AA Technical Framework

1. The published product conditions are updated in a set of applications prefixed with AA.PRD.CAT. 2. When a product is published, the records from AA.PRD.PRF. applications are deleted and records are created in a set of applications called AA.PRD.CAT. 3. When an arrangement is created for a product, the product conditions are fetched from these applications In this example we can see a sample of a published product condition for the MORTGAGE.OFFER product. Once our product is published, records representing its product conditions stored in AA.PRD.PRF. applications get deleted. A new record for each of the published product’s property is created in AA.PRD.CAT. applications, instead. In this slide the MORTGAGE.OFFER’s property NEWARRFEE has its conditions detailed within the AA.PRD.CAT.CHARGE application after the publishing process. Please note that AA.PRD.CAT. records’ contents and ID structure are the same as AA.PRD.PRF. records’.

Temenos University - August 2012

24

AA Technical Framework

Temenos University - August 2012

25

AA Technical Framework

The second concept we are going to discuss within this AA Technical Framework session is Product Tracking. 1. As we have previously seen, once a product is designed, proofed and published for the first, it could undergo many changes and this implies being re-proofed and re-published for many different time. 2. When a product is changed, it may have to affect any existing arrangements. How will T24 keep track of changes in existing product? As we are about to see, the main tool that the AA module provides for this purpose are two applications called AA.PRODUCT.TRACKER.CATALOG and AA.PRODUCT.TRACKER.PROOF.

Temenos University - August 2012

26

AA Technical Framework

As we know, when an existing product is re-published, T24 keeps track of the changes in the product properties. A dedicated routine compares the old published property records with the new ones to identify any amendments. This routine performs the following tasks – 1. It first checks if the product is being published for the first time 2. If it is not published for the first time, the product conditions are compared otherwise the tracking does not happen 3. Negotiation fields are ignored 4. If the action is PROOF, the comparisons done are updated onto a file called AA.PRODUCT.TRACKER.PROOF with the Product as ID 5. If the action is PUBLISH, the comparisons are not done. The update is done onto a file called AA.PRODUCT.TRACKER.CATALOG and the AA.PRODUCT.TRACKER.PROOF record is deleted 6. The record id’s in both the applications AA.PRODUCT.TRACKER.PROOF and AA.PRODUCT.TRACKER.CATALOG is that of the product id

Temenos University - August 2012

27

AA Technical Framework

1. Every time a product is proofed or published, T24 tries to track the changes that has happened to the product conditions using the AA.PRODUCT.TRACKER.PROOF or AA.PRODUCT.TRACKER.CATALOG applications. 2. There are various criteria based on which T24 decides if a product needs to be tracked or not 2.1 Products set to inheritance only are not tracked but if this product is changed, then the affected child products are tracked 2.2 If it is the first publish event, then the changes are not tracked 2.3 Classic products (i.e. standard non-AA T24 products like Accounts) are not tracked

Temenos University - August 2012

28

AA Technical Framework

Temenos University - August 2012

29

AA Technical Framework

Let’s try to understand how T24 tracks product changes with an example. Using the Product Builder tool, let us change the LIMIT Property of the ‘Small Business Loan’ product (SMALL.BUSINESS.LOAN). In R12, this product doesn’t show a LIMIT specific condition in its AA.PRODUCT.DESIGNER record as it inherits the LIMIT property conditions from its parent product, i.e. SB.LOAN.PARENT. If we assign a specific LIMIT property condition to the ‘Small Business Loan’ product this will imply a product update which requires a proofing/publishing process and that will be tracked by T24. Let’s test this now. As we can see the LIMIT’s condition for the loan product SB.LOAN.PARENT is set to SINGLE – this means that LIMIT’s condition for the child product SMALL.BUSINESS.LOAN will be also SINGLE. Let’s now try to change it to SHARED in SMALL.BUSINESS.LOAN.

Temenos University - August 2012

30

AA Technical Framework

Using the AA.PRODUCT.DESIGNER,AA version available under MB Menu, we add the value SHARED as a condition for the LIMIT property in the SMALL.BUSINESS.LOAN product. After committing, the record gets also authorised (as this is a self-authorising version) and we should re-proof and republish the product to make this new condition effective.

Temenos University - August 2012

31

AA Technical Framework

1.

2.

Once we have updated the SMALL.BUSINESS.LOAN product, we can now proof the product. In order for the product tracking applications to be activated, let us make sure that the AVAILABLE.DATE field of the corresponding AA.PRODUCT.MANAGER record is set to current or future date (in this example the system date is the 26th of January 2012 but we have set the available date of the product to the 27th of January 2012). After proofing the product and before publishing the product, records get created in an application called AA.PRODUCT.TRACKER.PROOF, which keeps track of the proofed changes. This is an ‘L’ type of file, which is therefore automatically updated by the system. The most important fields in AA.PRODUCT.TRACKER.PROOF are – • @ID – Which is the same as the corresponding AA.PRODUCT record ID • EFF.DATE The actual effective date on which the condition have been changed. This date would indicate on which date would the change be effected on the arrangement property. This field can be multi-valued if, like in this case, the product has been proofed to a future available date. • EFF.PERIOD This field represents the effective period after which the new property condition comes into effect. In addition to dated changes of a single Defined Property, the Product designer may also allow a Product to be defined with “timed” changes of its conditions. These timed changes may be defined as “condition changes” i.e. a standard product property is linked to one Defined Property and after a period of time switches to a different Defined Property. For example, when a Interest property follows a FIXED.INTEREST for first 6 months and switches to a FLOATING rate after that, then any amendments to FLOATING rate condition would update this field to 6M. This is an indication to the system not to apply this change onto arrangements which have not crossed this period yet. If the condition is not subject to time constraints (i.e. it is not applied only after a certain period of time), then this field will be blank • PROPERTY.CCY The Property and currency combination to indicate the currency condition for the property has been amended. When a property is a non-currency property, then this field would only hold the property id. • DESIGNER.KEY This field is particularly crucial. It contains the ID of the Condition applied to a certain Property within the current product: in other word, this field contains the key of the AA.PRD.DES. application which defines conditions associated with a Property. To sum up, if we look ad the framed associated-fields set, o PENALTYINT defines a SMALL.BUSINESS.LOAN product’s Property, o USD is the currency associated with it, o AL.PENALITY.RATE-USD-20110414 represents the ID of the conditioned defined within the AA.PRD.DES.INTEREST application, where INTEREST is the property class linked to the PENALTYINT property o SMALL.BUSINESS.LOAN Arrangements created from the 26 JAN 2012 or from 27 JAN 2012 will have the AL.PENALITY.RATE-USD-20110414 condition applied to the PENALTYINT property

Temenos University - August 2012

32

AA Technical Framework

As soon as SMALL.BUSINESS.LOAN product gets published, the AA.PRODUCT.TRACKER.PROOF record will be deleted and the application AA.PRODUCT.TRACKER.CATALOG will be updated instead. This is the base file where any changes to product conditions are updated and tracked after a product has been re-published. As we will see, after publishing these changes would be picked by a generic service process – called AA.ARR.PRODUCT.TRACKER – which will apply published amendments to the relevant arrangements. Note that, like AA.PRODUCT.TRACKER.PROOF, AA.PRODUCT.TRACKER.CATALOG is an ‘L’ type of application which is automatically updated by T24. Unlike the application described in the previous slide, however, it will only get cleared when the AA.ARR.PRODUCT.TRACKER job is executed. The other AA Product which you see in this screenshot have also been recently re-published. Fields in AA.PRODUCT.TRACKER.CATALOG are basically identical to AA.PRODUCT.TRACKER.PROOF’s fields.

Temenos University - August 2012

33

AA Technical Framework

Let’s now try to understand how Product Tracking applications work through a few Product Condition change scenarios. In the first scenario – 1. There are two different product conditions called ‘HELOC’, i.e. ‘Home Equity Line of Credit (3107)’, each of which has a different effective date (02 DEC 2009 and 26 JAN 2012). Both HELOC conditions are associated with the ACCOUNT Property Class but the HELOC-20120126 has been created afterwards and needs now to be associated to a product called ‘Home Equity Line of Credit (3107)’ 2. We associate the HELOC condition to the property ACCOUNT within the HELOC Product – please note that in this case we cannot provide the product condition suffix which indicates the condition’s effective date. After adding this condition, we re-proof and re-publish the product to make the change effective. If the T24 Business Date for the current Company (i.e. the value of the field TODAY in the DATES record for the current company) is the 30th of January 2012, which of the two conditions will be applied to the product? We can check this out by viewing either the record corresponding to ‘Home Equity Line of Credit (3107)’ which will appear in AA.PRODUCT.TRACKER.PROOF table after proofing or the AA.PRODUCT.TRACKER.CATALOG’s record, once we publish the aforementioned product.

Temenos University - August 2012

34

AA Technical Framework

1. As the current Company’s date is the 30th of January 2012, once we republish the aforementioned product with available date set as today the AA.PRODUCT.TRACKER.PROOF’s record will show that the CONDITION applied to the ACCOUNT property on the new product is HELOC-20120126, i.e. the closest date: when a product condition is back dated (the date is available as part of the product condition’s id), then the effective date is always T24’s current date for the product or the most recent. 2. For a future dated product condition, the future date is specified in the effective date for the product: in this case, the EFF.DATE field is set to the 30th of January 2012 because T24 today’s date for the current company is the 30th of January 2012 and because the AVAILABLE.DATE in the AA.PRODUCT.MANAGER record was also the 30th of January 2012. In case these two dates don’t match because the AVAILABLE.DATE is set to the future, the EFF.DATE field will be multi-valued in order to contain both. 3. The same fields’ content will appear in AA.PRODUCT.TRACKER.CATALOG once the HELOC product is published

Temenos University - August 2012

35

AA Technical Framework

Let us now have a look to a second scenario – 1. In this case we take in consideration two separated conditions with different IDs and same effective date associated to the ACTIVITY.RESTRICTION property class: • HELOC.DRAW (a condition associated with the Home Equity Line of Credit product which allows the amount disbursement within a lending arrangement) • HELOC.REPAY (which stops disbursement within a lending arrangement) 2. 3.

By searching on the AA.PROPERTY table, we can see that ACTIVITY.RESTRICTION property class is linked to two properties – AR.PAYOFF and ARRANGEMENT rules We decide to define that the ARRANGEMENT.RULES property within the HELOC.TEST product is using both HELOC.DRAW and HELOC.REPAY conditions as follows: • HELOC.DRAW will be applied to HELOC.TEST arrangements as soon as they are created while • HELOC.TEST arrangement should be switched to HELOC.REPAY condition after 9 years from their creation As we previously learnt, we can achieve this by having both conditions linked to the ARRANGEMENT.RULES property and by setting the ‘Effective’ field to the value 9Y for the HELOC.REPAY condition. In this way, if an arrangement is created TODAY it will use the HELOC.DRAW condition while T24 will automatically apply HELOC.REPAY to the arrangement’s ARRANGEMENT.RULES property, 9 years after it has been created (i.e. after the so-called ‘Effective Period’). As we will see in the next chapter, that this automatic change of conditions can be applied either by a set of multi-threaded background jobs.

Bearing in mind that T24 today’s date for the current company is the 30th of January 2012, let us now commit the HELOC.TEST product and check out the corresponding records in AA.PRODUCT.TRACKER.PROOF and in AA.PRODUCT.TRACKER.CATALOG after proofing/publishing.

Temenos University - August 2012

36

AA Technical Framework

1. Once we have re-proofed the HELOC.TEST product with available date set as today, the corresponding AA.PRODUCT.TRACKER.PROOF’s record will show that both HELOC.DRAW and HELOC.REPAY conditions have been associated with the currency-based ARRANGEMENT.RULES property class. From checking the list of conditions associated to the ACTIVITY.RESTRICTION property class, we can remember that both conditions were backdated to the 2nd of December 2009 – consequently the full conditions’ IDs used within the DESIGNER.KEY.3.1 and DESIGNER.KEY.3.2 fields, are HELOC.DRAW20091202 and HELOC.REPAY-20091202. For both conditions, the associated multi-value field EFF.DATE is set to 30 JAN 2012 (because this is today’s date in the company) but HELOC.REPAY-20091202 has its corresponding EFF.PERIOD set to 9Y (9 years), meaning that this condition will only kick off 9 years after the creation date of any HELOC.TEST arrangement set up after the 30th of January 2012; HELOC.DRAW-20091202 does not have an ‘Effective Period’ set, instead, i.e. is effective immediately for any HELOC.TEST arrangement with creation date >= 30 JAN 2012. 2. The same fields’ content will appear in AA.PRODUCT.TRACKER.CATALOG once the HELOC.TEST product is published

Temenos University - August 2012

37

AA Technical Framework

In this third and last scenario, we will take the consider again the HELOC.TEST product and republish it once we have created two future dated conditions for it. Specifically – 1. Under the PAYMENT.SCHEDULE Property Class, we create 2 copies of existing conditions called AL.CONSTANT and AL.INTEREST. The new conditions will are USD-based and have effective date set to 01 JAN 2015 and hence their IDs will be AL.CONSTANT-USD-20150101 and AL.INTEREST-USD-20150101 (note that these two new conditions were created for USD currency only because we want to apply them to the HELOC.TEST product, whose only available currency is USD) 2. These conditions are associated already with the HELOC.TEST product so nothing needs to be changed on the corresponding AA.PRODUCT.DESIGNER record – please note that one of them, AL.INTEREST, is supposed to be immediately applied to HELOC.TEST arrangements while the other, AL.CONSTANT, will be applied to an arrangement 9 years after its creation (as specified in the ‘Effective’ field). However we will re-proof and re-publish the product using AA.PRODUCT.MAGER to make the sure that HELOC.TEST picks up the conditions’ updates. T24 today’s date for the current Company hasn’t changed and it is the 30th of January 2012. Let’s see what happens to the product records in AA.PRODUCT.TRACKER.PROOF and AA.PRODUCT.TRACKER.CATALOG after proofing/publishing HELOC.TEST again.

Temenos University - August 2012

38

AA Technical Framework

1.

2.

3. 4.

5. 6.

As we are proofing the same record again on the same day, nothing has changed in the HELOC.TEST record in AA.PRODUCT.MANAGER, apart from the Product Version which has been updated from 2 to 2.1. Action field is manually set to ‘Proof’ and available date stays the same . Once proofing is successfully completed, AA.PRODUCT.TRACKER.PROOF is updated as usual with a record whose id is HELOC.TEST. This record contains only the changes which have been applied to the record during the last update, i.e. it records the fact that two future dated product conditions have been made available for HELOC.TEST. Both of them are linked to the currency-based SCHEDULE property (we can see that by the fact that they are set within the DESIGNER.KEY.1.1 and DESIGNER.KEY.1.2 dependent on PROPERTY.CCY.1 with value SCHEDULE-USD). The new conditions made available are AL.CONSTANT-USD-20150101 and AL.INTERESTUSD-20150101, precisely the same shown in the previous slide. Please note how, in the AA.PRODUCT.TRACKER.RECORD, the field EFF.DATE has been multivalued – • the first value of it, i.e. 01 JAN 2015, placed in EFF.DATE.1.1 represents the date in which HELOC.TEST arrangements will start using condition AL.CONSTANT-USD20150101, stored in the connected multi-value field DESIGNER.KEY.1.1 • the second value of it, i.e. 01 JAN 2015, placed in EFF.DATE.1.2 represents instead the date in which HELOC.TEST arrangement will have the AL.INTEREST-USD20150101 condition applied (as per DESIGNER.KEY.1.2) As AL.CONSTANT condition had an effective period of 9 years (i.e. it is supposed to be applied on an arrangement 9 years after it has been created), this will also be reflected in the AA.PRODUCT.TRACKER.PROOF record, within the EFF.PERIOD.1.2 field (value 9Y) Same will apply as well to the AA.PRODUCT.TRACKER.CATALOG record after the product has been published.

What does this update mean? What happens when a new arrangement gets created? As we have 4 different conditions with 4 effective dates, we can try to understand how they work together with one example. If on the 30th of January 2012, a new HELOC.TEST arrangement is created, its SCHEDULE property will get condition AL.INTEREST.USD.20110414. After 9 years, on the 31th of January 2021 (or the earlier working day), a COB job will update the SCHEDULE property to the AL.CONSTANT.USD.20110414 condition which had been assigned to the arrangement when it was created.

Temenos University - August 2012

39

AA Technical Framework

What does this update mean? What happens when a new arrangement gets created? As we have 4 different conditions with 4 effective dates, we can try to understand how they work together with one example. 1. If on the 30th of January 2012, a new HELOC.TEST arrangement is created, its SCHEDULE property will get condition AL.INTEREST.USD.20110414. After 9 years, on the 30th of January 2021 (or the earlier working day), a COB job will update the SCHEDULE property to the AL.CONSTANT.USD.20110414 condition which had been assigned to the arrangement when it was created. 2. If on the 30th of January 2015, which means after the effective date of the new condition (01 JAN 2015), another HELOC.TEST arrangement is created. In this second case the SCHEDULE property will get condition AL.INTEREST.USD.20150101. After 9 years from this date, on the 30th of January 2024 (or the earlier working day), a COB job will update the SCHEDULE property to the AL.CONSTANT.USD.20150101 condition which had been assigned to the arrangement when it was created. Let us now analyse what are the process that are looking after applying product updates to arrangements.

Temenos University - August 2012

40

AA Technical Framework

Temenos University - August 2012

41

AA Technical Framework

In all the Product Updates scenarios we have gone through so far, Product Conditions where changed before new arrangements for such product were created with no impact on already existing arrangements. In other words, all arrangements created before a certain product update were using old conditions, while arrangements created after a product update were supposed to be assigned a new condition (when effective date was appropriate for such condition). What if we do not want to create a new condition to influence future arrangements but, instead, we want to modify a back-dated condition to update already created arrangements as well? Updating previously created arrangements is not always possible. We can only do so for properties set to TRACKING within a product: if the property is set to TRACKING in the product, the changes need to be tracked for the existing arrangements. Else, this will not be required. This information is specified within the ARR.LINK field of the AA.PRODUCT.DESIGNER application, which allows the user to define the link between the product designer and the arrangement. The Product Builder supports 3 options in terms of how each arrangement will be affected by changes to its Product definition. NON.TRACKING – Once the arrangement has been opened, all conditions for a specific Property will be set for the duration of the arrangement. Subsequent changes to the “NON.TRACKING” product conditions will not affect already existing arrangements. TRACKING – The Product Conditions of a Property will contain values for all mandatory parameters. At the arrangement level the user cannot change any of the conditions of the Property. Throughout the duration of an arrangement any product level changes to a “tracking” property will be reflected in the arrangement. CUSTOM.TRACKING – This type of arrangement property behaves in a similar way to “tracking” properties except that individual conditions can be input (within negotiation limits) at the arrangement level. Any attributes, which have been input, will effectively become fixed for the duration of the arrangement. All other attributes will track changes at the product property.

Temenos University - August 2012

42

AA Technical Framework

1. The BNK/AA.ARR.PRODUCT.TRACKER service is used to both track the product changes and apply the changes on to the arrangements 2. It refers to the AA.PRODUCT.TRACKER.CATALOG table which, as we have seen, tracks updates for product conditions as soon as they are published When a new product condition is defined for property or attributes values are changed within a product condition. If the property is set to TRACKING in the product, the changes need to be tracked for the existing arrangements. The arrangement conditions for the property (AA.ARR. ) is not updated until the service AA.ARR.PRODUCT.TRACKER is run. This service will update the arrangement condition record with the changed conditions. When an activity is performed on a existing arrangement for the property, values of the attributes are merged from the product condition. So, although the arrangement condition record is not immediately updated, changes are reflected when the activity is performed. E.g. Let’s say that the product condition associated with the CLOSURE property (and with the property class with the same name) is updated in a product, changing the accounting conditions – for instance, a product closure conditions are changed from 14D.AFTER.MATURITY to XYZ. CLOSURE is a TRACKING property, therefore this kind of change will not only affect new arrangements created after the change but also existing arrangements which were created before the new condition becomes effective. This means that anytime a CLOSURE-related activity takes place on an arrangement belonging to such product (such as ACCOUNTS-CAPITALISE-CLOSURE*ACTUAL), the new condition will be default attributes’ values on the arrangement record.

Temenos University - August 2012

43

AA Technical Framework

Like any other service in T24, BNK/AA.ARR.PRODUCT.TRACKER has been built through the creation of a routine, which has been set up in T24 through PGM.FILE, then the creation of a record in the BATCH and then input & authorisation of a record in TSA.SERVICE which has the same ID as the BATCH record (this comes preconfigured with your installation). In this screenshot, we can see all these three records. If we take a look, in particular, to the PGM.FILE record (a routine called AA.ARR.PRODUCT.TRACKER), we notice that this is a Batch job (as it has the field TYPE set to B) and that it is multi-threaded, because the field BATCH.JOB is set to @BATCH.JOB.CONTROL. Moreover, the ADDITIONAL.INFO field is set to .NTX. When a batch job is set as .NTX, it means that the transaction boundary for this job is not controlled by BATCH.JOB.CONTROL(the heart of COB) routine, but is done through some other means. For AA.ARR.PRODUCT.TRACKER, the transaction boundaries are defined by OFS.BULK.MANAGER (for additional information on OFS.BULK.MANAGER please refer to the Open Financial Services training course). Now, if we do a search on the BATCH table and we look for all the BATCH records containing the AA.ARR.PRODUCT.TRACKER job, we’ll find out that at least two records are present – one record has no batch stage, which means that this record has a corresponding one in TSA.SERVICE, which shares the same ID and which can be run as a stand-alone service; the other record instead has a Batch Stage (S022) which means that this background process will be run as part of COB. In other words, AA.ARR.PRODUCT.TRACKER routine can be run either as a service or as part of the Close of Business process, during the Start of Day phase. Please note that in this screen-shot, there are 8 BATCH records containing AA.ARR.PRODUCT.TRACKER because each of this records operate on a set of Financial files which are lead-company specific and, in the sample installation taken in consideration, there are 4 lead companies. Each of these services/COB processes will operate on the set of files belonging to one specific lead company – hence we need two BATCH records for each lead company. The mnemonic of the corresponding lead company represents the prefix of the BATCH record ID (e.g. BNK is the mnemonic of company GB001-0001, in this installation, and hence the Product Tracker service will be called BNK/AA.ARR.PRODUCT.TRACKER while the BATCH record ID of the COB process will be BNK/AA.EOD.PROCESS). The precise structure of Product Tracker COB processes will be outlined in the next chapter.

Temenos University - August 2012

44

AA Technical Framework

Temenos University - August 2012

45

AA Technical Framework

We have previously seen that changes on product conditions may affect arrangements if the condition has its connected ARR.LINK field set to TRACKING or CUSTOM.TRACKING. We have also seen that, when an arrangement is affected by an update in a product condition, values of attributes are taken from the updated conditions when the appropriate activity is performed e.g. if a condition linked to the INTEREST property class and to the PRINCIPALINT property is updated and if it is set to TRACKING/CUSTOM.TRACKING, then the new conditions will affect arrangements’ attributes when a LENDING-ACCRUE-PRINCIPALINT activity is performed – in other words, if the interest is increased or decreased for a product and this condition is tracking, then the activity which calculates interest accrual on existing arrangements of such product will take in consideration the change from the moment it is made effective. Now, many of the activities affected by tracking properties are, in fact, what we call scheduled activities. Scheduled activities are activities which should be run on arrangements automatically according to a specific schedule, which will be read by background jobs during Close of Business. The application used to store this kind of activities is called AA.SCHEDULED.ACTIVITY. @ID – the id of the record in this file is the same as that of the arrangement id. What you see here is a sample record of arrangement AA12024R57Q7. ACTIVITY.NAME –The field ACTIVITY.NAME is used to specify the name of the activity that has to take place LAST.DATE – specifies when this activity was run last NEXT.DATE – specifies when this activity will run next NEXT.RUN.DATE – is the nearest date on which an activity is scheduled to run for an arrangement. This is the lowest date among the NEXT.DATE fields (please note that, like in the example given, each AA.SCHEDULED.ACTIVITY record can contain multiple activities – NEXT.RUN.DATE is the soonest date in which any of these activities will be run on the current arrangement) Important notes on AA.SCHEDULED.ACTIVITY – • Whenever AA.ARR.PRODUCT.TRACKER runs, it tracks the changes to a product and applies the changes to the appropriate arrangements. It also updates AA.SCHEDULED.ACTIVITY file with the updated activity information • AA.SCHEDULED.ACTIVITY is a ‘L’ type of file and so it is automatically updated by T24, as described in the previous point, and allows no manual update • AA.SCHEDULED.ACTIVITY has classification FIN – which means that this application may be associated to multiple tables at the database level (one per lead company)

Temenos University - August 2012

46

AA Technical Framework

FAA.NEXT.ACTIVITY files act as list files that cannot be directly accessed from T24, but only seen from jshell. They hold records that have to be processed during COB and ID structure for those records in , where DATE is the NEXT.RUN.DATE value picked from AA.SCHEDULED.ACTIVITY. Basically what happens is that, during COB, AA.SCHEDULED.ACTIVITY is not read, but AA.NEXT.ACTIVITY file is read, and then a filter routine is called to check if an activity has to processed on the current day. Please note that, like AA.SCHEDULED.ACTIVITY, also F.AA.NEXT.ACTIVITY files are lead company-specific which means you may have multiple ones. You can tell which lead company they are linked to through their filename, which includes the company mnemonic. In this example FBNK.AA.NEXT.ACTIVITY contains the company mnemonic BNK and belongs to the Master company GB001-0001. Consider the first record, AA12024R57Q7-20120226. If you look at the AA.SCHEDULED.ACTIVITY application for the arrangement, the NEXT.RUN.DATE value is 26-FEB-2012, that is why you have a record by id AA12024R57Q7-20120226. When the list file is picked for processing, all the records are selected and then a filter routine is called to filter the records to be processed today, if today’s date is 26-FEB-12, then the activity scheduled on that date is processed, otherwise its skipped. If a record is processed today, the dates are cycled, AA.SCHEDULED.ACTIVITY is checked if there is any other activity to be processed for another date, if yes, the F.AA.NEXT.ACTIVITY record is updated with the next possible activity to be performed. If there are no other activities for another date, the old record in AA.NEXT.ACTIVITY for the arrangement is deleted.

Temenos University - August 2012

47

AA Technical Framework

The BATCH list on the top left-hand side of the screen shows us the list of AA Tracking-related COB processes within an installation with 4 lead companies. As we can see, in this kind of installation there are a total of 8 AA Tracking processes, 2 for each lead company. These processes are lead company-specific because they are in charge of processing financial files (and, as we know, each lead company has its own set of financial files). Each lead company owns two kind of processes – 1. /AA.EOD.PROCESS which has batch stage S022. As previously seen, this process contains the AA.PRODUCT.TRACKER job which reads published product updates from AA.PRODUCT.TRACKER.CATALOG and updates activities consequently (in particular, it records changes on the AA.SCHEDULED.ACTIVITY application). AA.EOD.PROCESS is run for all lead companies during the System Wide stage of COB (‘S’ stage). We will see how this BATCH record is structured in the next slide. 2. /AA.SOD.PROCESS which has batch stage D250, which means it is executed afterwards, during the ‘Start of Day’ (D stage). We will also analyse what this process does and which job it contains as we go along.

Temenos University - August 2012

48

AA Technical Framework

1. As seen in the previous slide, there are two kind of COB jobs which are dealing with AA Tracking. 1.1 AA.EOD.PROCESS 1.2 AA.SOD.PROCESS 2. These processes are lead-company specific – which means that you will have a set of two for each lead company in your installation. Each AA.EOD.PROCESS contains the same 3. Each of the BATCH records are made up of few jobs 4. AA.EOD.PROCESS, this batch record is processed during the System-Wide stage of COB (S022) 4.1 AA.DELETE.NAU.ACTIVITIES deletes unauthorised AA activities (for this reason it is important that all INAU queues for AA activities are processed before Close of Business begins) 4.2 AA.ARR.PRODUCT.TRACKER is the routine that you learnt in the previous slides. This routine can run as a service or a COB job. Its main job is to track a product for changes. 4.3 AA.COB.PAY.IN.OUT is a job used to process COB payments for AA but is out of scope for this course 4.4 AA.SERVICE.PROCESS this is the actual routine that reads AA.SCHEDULED.ACTIVITY file and processes the appropriate activities for the arrangement.

Temenos University - August 2012

49

AA Technical Framework

1. AA.SOD.PROCESS, this batch record is processed during the Start-of-Day stage of COB (D250) 3.1 AA.COB.PAY.IN.OUT 3.2 AA.SERVICE.PROCESS 3.3. AA.CREATE.NAU.ACTIVITIES – automatically generates scheduled activities on an arrangement (which are going to be placed under the unauthorised tables of AA.ARRANGEMENT.ACTIVITY application) You must notice that the batch jobs AA.COB.PAY.IN.OUT and AA.SERVICE.PROCESS are executed twice during COB, once during System Wide and next during Start-Of-Day as soon as the T24 date changes to the next working day. At this stage, you will probably wonder where we can check which COB process is running which activity – this is what we are going to see on the next slide.

Temenos University - August 2012

50

AA Technical Framework

As we learnt from the AA Introduction course, each AA.ACTIVITY.CLASS record will define the list of Actions to be applied on the given list of property classes for a given process in the activity. Temenos releases AA.ACTIVITY.CLASS records for product lines and its property classes or the arrangement (E.g. LENDINGNEW-ARRANGEMENT, INTERNET.SERVICE-NEW-ARRANGEMENT, LENDING-UPDATE-INTEREST etc.). When properties are linked to AA.PRODUCT.GROUP, the system generates AA.ACTIVITY records which are property specific named instances of AA.ACTIVITY.CLASS. E.g. when a record in AA.PRODUCT.GROUP for the product line LENDING with properties LOANINT (Interest Property Class) and REPAYMENT (Payment Schedule Property Class) is authorised, 2 corresponding AA.ACTIVITY records are created – LENDINGUPDATE-LOANINT and LENDING-UPDATE-REPAYMENT. Consequently, an ACTIVITY definition will be linked to the ACTIVITY.CLASS and when the activity is triggered, the actions to process will be determined by referring to the activity class (for more information on AA activity classes please refer to the AA Introduction presentation). The three AA.ACTIVITY.CLASS fields which are interesting for us now is ACTIVITY.TYPE, BATCH.NAME and BATCH.SEQ. ACTIVITY.TYPE indicates how the activity would be triggered and indicate the characteristic of this activity. More than one type indicates the activity would share the characteristic of all types specified. The values of ACTIVITY.TYPE which are relevant for AA Tracking are SCHEDULED and SOD-PROCESS. SCHEDULED – When an activity class is set to SCHEDULED it means that this activity can be executed as part of COB. This activity will be executed during the batch process AA.EOD.PROCESS. SOD-PROCESS – When an activity class is set to SOD-PROCESS it also specifies that this activity is also a scheduled activity and it will be executed as part of Start-Of-Day procedures too, through batch process AA.SOD.PROCESS. BATCH.NAME is only going to be used when ACTIVITY.TYPE is set to SCHEDULED or SOD-PROCESS, to specify the batch name in which the activity should be run along with a field called BATCH.SEQ that determines when this activity will be run. BATCH.SEQ (labeled as ‘Sequence’ in this version) assumes significance only when ACTIVITY.TYPE contains SCHEDULED. Several activities may be scheduled to be processed for an arrangement on the same date and the sequence the activities follow is important. This is defined as part of the ACTIVITY.CLASS definition In this slide we have taken as an example an activity class called LENDING-AGE-OVERDUE. In this record, the field ACTIVITY.TYPE is set to SCHEDULED and also to SOD-PROCESS, BATCH.NAME is set to both AA.EOD.PROCESS and AA.SOD.PROCESS while BATCH.SEQ is set to 90. This holds that the activity LENDINGAGE-OVERDUE will be executed as part of batch process AA.EOD.PROCESS and, again, as part of the AA.SOD.PROCESS batches, as 90th activity in both cases. Temenos decides the sequence number for an activity.

Temenos University - August 2012

51

AA Technical Framework

Temenos University - August 2012

52

AA Technical Framework

1. Simulation refers to the possibility to perform AA operations and predict their outcome without actually applying these changes to LIVE tables 2. The Simulation tool facilitates customers’ informed decision making 3. The AA module now provides a mechanism through which it is possible to simulate both the creation of new arrangements and activities on existing arrangements

Temenos University - August 2012

53

AA Technical Framework

Temenos University - August 2012

54

AA Technical Framework

The simulation process involves three stages – 1.1 The first one is data capture, where the simulation data is recorded. For example, if you want to change the principal interest rate for an arrangement, the information to be captured would be the new interest that you’d like to apply 1.2 In order to complete the second stage, we must define the period of time taken in consideration by our simulation, e.g. 1 day, a week, a month etc. In order to do so, we create a record in the AA.SIMULATION.RUNNER application. Once this record is authorized an OFS message is created and stored in the list file AA.SIMULATION.SERVICE.LIST, waiting to be posted to T24 1.3 The third stage consists of running the so-called ‘Simulation Service’, a background process named BNK/AA.SIMULATION.SERVICE which reads the content of the AA.SIMULATION.SERVICE.LIST file and posts the OFS messages generated during the ‘Simulation Period Definition’ stage. This third step is the core of the simulation process. Note: If you find the changes you have simulated satisfying, you can also confirm your activities and make them update LIVE records

Temenos University - August 2012

55

AA Technical Framework

Temenos University - August 2012

56

AA Technical Framework

As we have learnt about in the Overview, the first stage of simulation is called ‘data capture’. 1. It consists of recording the arrangement information required for our simulation. Data capture is a manual process which should be carried out by a T24 user 2. Information to be used to simulate an arrangement activity is stored in an application called AA.SIMULATION.CAPTURE 3. This application resembles very much AA.ARRANGEMENT.ACTIVITY. Both applications share similar fields with very little variations 4. A set of applications of the type AA.SIM. store conditions for simulated arrangement’s activities in the same way in which AA.ARR. applications define conditions for real arrangements. The next slide will show how AA.SIM. applications are structured

Temenos University - August 2012

57

AA Technical Framework

1. AA.SIM. applications are similar to AA.ARR. tables, but the former stores product conditions belonging to simulated arrangement while the latter defines conditions for LIVE arrangements 2. IDs in AA.SIM applications follow the same structure as the IDs in AA.ARR. applications: -<Effective Date>- On this slide, we can view a few records records from AA.SIM.PAYMENT.SCHEDULE and AA.SIM.INTEREST applications. If you notice, the ids of these applications are similar to that of AA.ARR. applications

Temenos University - August 2012

58

AA Technical Framework

Let us now compare and contrast AA.ARRANGEMENT.ACTIVITY and AA.SIMULATION.CAPTURE applications. As you know, each record in the AA.ACTIVITY.CLASS application defines the list of Actions to be applied on the given list of property classes for a given process in the activity and these activities are being triggered through AA.ARRANGEMENT.ACTIVITY, if we want to update or create a LIVE arrangement. The activity class LENDING-CHANGE-INTEREST, for instance, defines the actions to be applied for properties for the LENDING-CHANGE-PENALTYINT and LENDING-CHANGE-PRINCIPALINT activities. We may choose to perform one of such activities or to simulate it. The difference between an actual activity (performed on AA.ARRANGEMENT.ACTIVITY) and a simulated activity (which uses AA.SIMULATION.CAPTURE) is that, the former will update the AA.ARR.INTEREST application while the latter will affect the AA.SIM.INTEREST application, instead (because INTEREST is the property class affected by a LENDING.CHANGE.PENALTYINT application). This example enforces the idea that different sets of applications are updated if we choose to simulate an activity rather than perform it for real. Also, since we are only capturing data, at this point the action routines will not be triggered. Basic validation routines will take place instead, so that we perform on simulated activities the same kind of errors-check we would have on actual activities.

Temenos University - August 2012

59

AA Technical Framework

A new activity type has been introduced for simulation called SIMULATION for the AA.ACTIVITY.CLASS application. The purpose of this type is to specify that a particular activity class can be used only for simulation, this particular activity cannot be made LIVE. This means that LENDING-CALCULATE-PAYOFF can be used for simulation only. If no SIMULATION activity type is added to an AA.ACTIVITY.CLASS record, instead, it means that this activity class can be used for both actual update on LIVE tables and for simulation purposes.

Temenos University - August 2012

60

AA Technical Framework

The AUTO.RUN field in AA.SIMULATION.CAPTURE can be used during Simulation capture scenarios where there is just one change and, consequently, the user may want to, somehow, bypass some stages of the simulation process. The field is only relevant for AA.SIMULATION.CAPTURE application and the following options are supported: 1. SIMULATE : If this option is selected, the system will carry out the simulation as soon as the AA.SIMULATION.CAPTURE record is authorised. 2. EXECUTE : The EXECUTE option ensures that the execution of simulation is triggered as soon as the simulation capture record is authorised, transforming therefore the AA.SIMULATION.CAPTURE record into a LIVE record in the AA.ARRANGEMENT.ACTIVITY application. It is assumed that the user would have simulated first before using this option. 3. DIRECT.EXECUTE: If the user does not want to follow the usual 2-steps process of simulating and executing, then this option may be used as it will execute both steps automatically. As AUTO.RUN is not a mandatory field, a ‘None’ option is also available.

Temenos University - August 2012

61

AA Technical Framework

The field RELATED.ACTIVITY in the application AA.ACTIVITY enables to connect two simulated activities together so that the activity included in the field RELATED.ACTIVITY is executed immediately after the main activity has been authorised – in the scenario shown on this slide, LENDING-DISBOURSECOMMITMENT will be simulated as soon as LENDING-NEW-ARRANGEMENT is simulated. Please note that RELATED.ACTIVITY is used ONLY when you are simulating an Arrangement scenario and only for LENDING and DEPOSIT product lines at the moment – also, currently the system support just one simulated activity per main AA.ACTIVITY record. For example, when a NEW arrangement is to be simulated for 2 schedules, the schedules could be run only after the arrangement is disbursed (either fully or partially). But, disbursement is always transaction-driven and may not be captured using a AA.SIMULATION.CAPTURE application. To automatically trigger an activity after the main activity (i.e. the activity mentioned in the AA.ACTIVITY record’s ID), this field may be used. So, a LENDING-NEW-ARRANGEMENT would have LENDING-DISBURSE-COMMITMENT as its RELATED.ACTIVITY. Similarly, automatic repayments on DUEs may be triggered by using this field. The disbursement and repayments generally assumed to be FULL disbursement and payment, but this may be altered within the AA.SIMULATION.RUNNER application to simulate partial disbursements and payments (a full description if AA.SIMULATION.RUNNER will be given in the coming slides). Only an activity can be set up as RELATED.ACTIVITY of another one, only if it belongs to the main activity’s ‘Related Activity Class’ – this information can be checked against the AA.ACTIVITY.CLASS linked to the main AA.ACTIVITY record, using the RELATED.ACT.CLASS field. User Activities can also be defined as ‘related activities’ as long as they belong to the core Activity class.

Temenos University - August 2012

62

AA Technical Framework

As we have seen, a related activity can only be defined in AA.ACTIVITY if it belongs to the activity class mentioned in the main activity’s corresponding AA.ACTIVITY.CLASS record. This implies that we will get an error message if we try to set up a related activity which does not comply with the required ‘related activity class field’. In this example, for instance we are trying to set up LENDING-DECREASECOMMITMENT as a related activity for LENDING-NEW-ARRANGEMENT. LENDING-DECREASE-COMMITMENT activity is derived from the LENDINGDECREASE-TERM.AMOUNT property class while the LENDING-NEWARRANGEMENT activity belongs to an class with the same ID. If we check the related activity class for LENDING-NEW-ARRANGEMENT, we’ll see that it is LENDING-DISBURSE-TERM.AMOUNT not LENDING-DECREASE-TERM.AMOUNT – consequently, we will get an error.

Temenos University - August 2012

63

AA Technical Framework

What you see here is a new simulated arrangement, the activity triggered here is LENDING-NEW-ARRANGEMENT. If you look at the activity logs for this arrangement, there is a disbursal activity of COMMITMENT (LENDING-DISBURSECOMMITMENT) property has taken place. Please note that the enquiry used to access this simulated record is AA.FIND.ARRANGEMENT.SIM based on the AA.SIMULATION.RUNNER’s live table.

Temenos University - August 2012

64

AA Technical Framework

Temenos University - August 2012

65

AA Technical Framework

As previously learnt, the second stage of the simulation process is called ‘Simulation runner’ or ‘Simulation period definition’. This stage consists of defining the period of time taken in consideration and actually running the Simulation. 1. The type ‘H’ Financial application AA.SIMULATION.RUNNER is used for this purpose – this is a log for all requests of Simulation or Execution of Simulation issued by end-users and defines the period taken in consideration by the Simulation 2. A record in AA.SIMULATION.RUNNER is automatically created when you authorise a AA.SIMULATION.CAPTURE entry, according to the updates made on the AUTO.RUN field. 3. Authorising records in AA.SIMULATION.CAPTURE and the following updates in AA.SIMULATION.RUNNER also generate OFS strings if SIMULATE, EXECUTE or DIRECT.EXECUTE options are selected. If the AUTO.RUN field was set to SIMULATE, it would generate an OFS string for simulation, if AUTO.RUN field was set to EXECUTE or DIRECT.EXECUTE, then a OFS string to actually execute the simulation would be generated. The OFS string is stored a list file whose name follows the structure F.AA.SIMULATION.SERVICE.LIST, from where it will be picked up by AA.SIMULATION.SERVICE for further processing. If AUTO.RUN is left empty, instead, the record authorisation in AA.SIMULATION.CAPTURE will not result in any update in the Simulation Service’s list file – if you plan to create AA.SIMULATION.RUNNER record manually, you should set AUTO.RUN field to blank during data capture, create a record in AA.SIMULATION.RUNNER and specify the simulation capture reference manually .

Temenos University - August 2012

66

AA Technical Framework

After the basic information for simulation has been captured, the next step is to actually run the simulation. AA.SIMULATION.RUNNER application is used to run the simulation from a given start date to end-date. By using this application we can monitor how a simulated activity would affect an arrangement within a specific period of time. In this slide, you can see a sample AA.SIMULATION.RUNNER record. The most relevant fields we should learn about are – 1.

ARRANGEMENT.REF: This field represents the reference ID of the arrangement, which can be an existing or a simulated one. If this field is input with an existing arrangement reference, it means the AA.SIMULATION.RUNNER record represents an activity simulated on an existing arrangement. If this field is input with a simulated arrangement ID, instead, the AA.SIMULATION.RUNNER record will be used for the simulation of an arrangement creation

2.

SIM.RUN.DATE , SIM.END.DATE: A Simulation is run for a period. You can specify the period using the SIM.RUN.DATE and SIM.END.DATE fields. The former field is used to specify the start date and the later field is used to specify the end date for the simulation. If the SIM.END.DATE is left blank, the simulation will run up to the Maturity date of the arrangement

3.

SIM.CAPTURE.REF : This field is used to specify the simulation capture reference that has to be executed by this simulation runner record, the id of the AA.SIMULATION.CAPTURE records matching with this AA.SIMULATION.RUNNER entry. Multiple simulations can be run using a single simulation runner record. You need to multi-value this field and specify the simulation capture reference ids.

4.

STATUS: denotes the status of the simulation runner. Options available are – • COMPLETED – SUCCESSFULLY, which means that simulation runner has been executed successfully • COMPLETED – ERROR, that denotes the simulation runner has completed but it incurred some errors while • Processing…, which indicates that the simulation runner is currently getting executed

5.

INPUTTER/AUTHORISER: these fields contain, as usual, the USER ID of the T24 user who inputted/authorised the record. Please note that, if the current AA.SIMULATION.RUNNER record is generated by the system after a AA.SIMULATION.CAPTURE record has been authorised, the INPUTTER/AUTHORISER indicated in AA.SIMULATION.RUNNER will be the same as the ones indicated in the audit trail of the corresponding AA.SIMULATION.CAPTURE record.

Temenos University - August 2012

67

AA Technical Framework

Let us take a look at another AA.SIMULATION.RUNNER sample. In this screenshot, we can see that this application logs details regarding activities to be executed or that have been executed. The fields dedicated to show this information are – S.ACTIVITY is used to specify that a scheduled activity has been simulated. SIM.S.DATE denotes the date on which a scheduled activity has been simulated. S.RUN.STAGE indicates that the corresponding activity is a scheduled activity and will be get updated to “SCHEDULED” when the simulation process is completed U.ACTIVITY indicates that a user activity, like change interest or update charge, has been simulated/should be simulated. SIM.U.DATE denotes the date on which the user activity has been/should be simulated. U.RUN.STAGE indicates that this activity is user-specific. This field will be updated with a value “USER” when the simulation completes T.ACTIVITY: can be used to simulate transaction activities – this will appear as a imputable field when we open a AA.SIMULATION.RUNNER record in editable mode. SIM.T.DATE is used to denote the date on which the transaction activity will be/has been simulated. It is an editable field T.RUN.STAGE is updated by the system with a value “TRANSACTION” to specify that it is a transaction activity, as soon as the simulation is completed.

Temenos University - August 2012

68

AA Technical Framework

Other important fields in AA.SIMULATION.RUNNER are – RUN.S.ACT, which denotes whether a Scheduled activity has to be simulated or not. This field is associated with SIM.S.DATE and is update by the system RUN.U.ACT, that defines if a User activity should be simulated and is linked to SIM.U.DATE. This field can be modified manually and it can be set to YES or NO. RUN.T.ACT, that indicates whether a Transaction activity has to be simulated or not and is associated with SIM.T.DATE. This field is also available for manual input and the options that can be selected are YES or NO. EXECUTE.SIMULATION is a field that allows the user to decide whether the simulation can be executed, i.e. transformed into a live arrangement. YES can be set if the STATUS of the AA.SIMULATION.RUNNER record is ‘Simulated Successfully’

Temenos University - August 2012

69

AA Technical Framework

What you can see in this screenshot is the output of a query on the FBNK.AA.SCHEDULED.ACTIVTY$SIM table, which is visible from R12 Browser by typing the command ‘AA.SCHEDULED.ACTIVITY$SIM L’. 1. The $SIM files of AA.SCHEDULED.ACTIVITY application hold the scheduled activities generated for a simulation within a certain lead company and its branches 2. The records from this file are later moved to the AA.SCHEDULED.ACITIVITY’s live file if the simulation is executed (made live)

Temenos University - August 2012

70

AA Technical Framework

1. Overrides are accepted by default during simulation, while errors will be reflected in the status of the AA.SIMULATION.RUNNER 2. As previously mentioned, the AA.SIMULATION.RUNNER record will hold complete information about the activities performed while running the simulation 3. The same simulation runner record can be amended for further simulations 4. If we choose to add new Transaction or User activities, the fields SIM.U.DATE or SIM.T.DATE should be filled in with the date in which the activity has to take place. And also, the fields RUN.U.ACT or RUN.T.ACT should be set to ‘YES’ in order to make sure that the activity actually gets triggered during simulation

Temenos University - August 2012

71

AA Technical Framework

As previously, mentioned when we either create a live AA.SIMULATION.RUNNER record manually or by authorising a corresponding AA.SIMULATION.CAPTURE record, an OFS string is generated for the simulation in a list file called F.AA.SIMULATION.SERVICE.LIST. The record id follows the format <Simulation Runner record ID>.SIMULATE. To process the OFS strings, you need to run a service called BNK/AA.SIMULATION.SERVICE. In this screenshot we can see the content of the FBNK.AA.SIMULATION.SERVICE.LIST file, which can be accessed only by jshell, and also the details of one of the records it stores – the record content is of course an OFS message. When the AA.SIMULATION.SERVICE is started it looks for records in the activation file AA.SIMULATION.SERVICE.LIST and it starts processing them finally performing the actual simulation. This is the third and last stage of the simulation process as we will see in the coming slides.

Temenos University - August 2012

72

AA Technical Framework

Temenos University - August 2012

73

AA Technical Framework

As previously anticipated, BNK/AA.SIMULATION.SERVICE is a service which carries out simulation in the strict sense of the word, while AA.SIMULATION.CAPTURE will store the arrangement details to be used during simulation and AA.SIMULATION.RUNNER will set up some important parameters required for the simulation to be executed (e.g. period to be taken in consideration and extra-activities to be performed). 1. This service does the actual job of simulation and execution of simulation 2. It stores the data in the required files, like the $SIM files eg. AA.ARR.TERM.AMOUNT$SIM and F.SIMULATION.DETAILS. You will learn about these files a little later during the course. 3. It also updates the AA.SIMULATION.RUNNER record with the status of the simulation, like “COMPLETED – SUCCESSFULLY” or “COMPLETED – ERROR” once the simulation has completed. Please note that, if a record is created in AA.SIMULATION.RUNNER but the simulation service is not started, the STATUS field will be stuck to the “Processing…” value.

Temenos University - August 2012

74

AA Technical Framework

In this slide you can see a screenshot of the TSA.SERVICE record of BNK/AA.SIMULATION.SERVICE – this is a so-called ‘Auto service’, which means that, once you have started it, it will keep on running until it is manually stopped. If you check the PGM.FILE entry for the service routine, the ADDITIONAL.INFO field has been set to .NTX. This again means that the transaction management is not done by BATCH.JOB.CONTROL but by some other method. Here OFS.BULK.MANAGER takes care of transaction management for this service. Obviously, the field ACTIVATION.FILE is set to ‘Yes’ as this routine has its own proprietary list file (the previously mentioned F.AA.SIMULATION.SERVICE.LIST)

Temenos University - August 2012

75

AA Technical Framework

On running the service, it picks records from the F.AA.SIMULATION.SERVICE.LIST file and starts processing. Please note that, in the simulation service list presented in this screenshot there is also a record pertaining to Execution of simulation on top of 3 Simulationspecific records. The simulation is being brought to live when you carry out an ‘Execution of simulation’. You can create an .EXECUTE type of record in the simulation service list file, either setting the AUTO.RUN field to EXECUTE or DIRECT.EXECUTE in the AA.SIMULATION.CAPTURE application (and then authorising the record) or using the EXECUTE.SIMULATION field in the AA.SIMULATION.RUNNER application – in both cases, an OFS record with id following the syntax <Simulation Runner record ID>.EXECUTE is created. The service AA.SIMULATION.SERVICE will be used to process also this second kind of OFS string.

Temenos University - August 2012

76

AA Technical Framework

Temenos University - August 2012

77

AA Technical Framework

Several files are updated throughout the simulation process and they can be used to monitor the simulated updates, the tables involved, the outcome of simulated activities etc. One of them is AA.ARRANGEMENT.SIM. AA.ARRANGEMENT.SIM is the application that has been introduced to store details about arrangements that have been processed by the simulation service. AA.ARRANGEMENT.SIM lists both new simulated arrangements and simulated activities on an existing LIVE arrangement. It stores for simulated activities the same kind of information that the AA.ARRANGEMENT application shows for LIVE activities – the fields on these two applications are also very similar.

Temenos University - August 2012

78

AA Technical Framework

1. As you know, the application AA.ACTIVITY.HISTORY is used to store log about the list of activities that has taken place on an arrangement. Likewise, to trace the information about the simulated activities that have happened on an arrangement, you can refer to an application called AA.ACTIVITY.HISTORY.SIM. The id of records in this application is the same as the arrangement ID 2. If you look at the AA.ACTIVITY.HISTORY.SIM record in this screenshot, it holds the AA.SIMULATION.CAPTURE id within the ACTIVITY.REF field instead of AA.ARRANGEMENT.ACTIVITY. It holds details about the simulated activity called LENDING-CHANGE-PRINCIPALINT that has happened on the arrangement AA12026QP4D0

Temenos University - August 2012

79

AA Technical Framework

When we discussed the AA.SIMULATION.SERVICE, we had stated that this service updates F.SIMULATION.DETAILS and the so-called $SIM files. You will now learn about these files in detail. 1. The $SIM is a new file suffix that has been introduced in T24 for simulation 2. As the name suggests, these files are used to hold the simulated copy of a record What you see in this screenshot is a list of the simulated records of TERM.AMOUT property class, stored in a file of the type F.AA.TERM.AMOUNT$SIM file – the content of this file is accessible from T24 using the command ‘AA.ARR.TERM.AMOUNT$SIM L’. The id of these records follows the format --<Effective Date>.<Sequence Number>%. When a simulation is performed, the simulated data for a property is stored in these files. Also, we can see the FILE.CONTROL record for the application AA.ARR.TERM.AMOUNT that is used to hold the arrangement conditions for TERM.AMOUNT property class. A new suffix $SIM has been included for this application wherein the simulated information for TERM.AMOUNT property class will be stored Please note that $SIM suffix is available for all property classes-related applications.

Temenos University - August 2012

80

AA Technical Framework

1. F.SIMULATION.DETAILS is a general log of simulation. This file is accessible from jshell only 2. IDs of records in this application follow the same structure as AA.SIMULATION.RUNNER IDs’ 3. F.SIMULATION.DETAILS includes detailed information like files names which have been read/updated during the simulation process, reference ids of activities simulated, operations carried out during simulations, simulation date and user involved etc

Temenos University - August 2012

81

AA Technical Framework

The simulation engine includes a routine called SIM.READ designed to read simulated records. There are many files being updated during a simulation like the $SIM files, the AA.SIM.XXX files and F.SIMULATION.DETAILS. SIM.READ is responsible for selecting records from the appropriate files. It does the following 1 Checks if there a specific $SIM file exists for the current simulation record – If yes, it reads it 2 If not, it retrieves simulation-specific information from F.SIMULATION.DETAILS 3 If the routine is not able to find a simulation record in both the $SIM files and F.SIMULATION.DETAILS, it searches and reads from corresponding LIVE files by calling F.READ

Temenos University - August 2012

82

AA Technical Framework

1. A specific insert file is available for routines to be invoked during the Simulations 2. It holds simulation related common variables 3. You can see here a couple of frequently-used variables Row 1: aaSimCapture is used to hold the flag for simulation capture. Row 2: aaSimRef is used to hold the AA.SIMULATION.RUNNER Id

Temenos University - August 2012

83

AA Technical Framework

Some changes have been made on the core routine OFS.BULK.MANAGER to help it operate within the Simulation engine – 1.

OFS.BULK.MANAGER will check if the incoming request is a simulated request

2.

If yes, an after image of the current transaction will be captured while the current transaction will be aborted

3.

Finally a call to the LOAD.SIMULATION.UPDATES routine will be made within a transaction block

Please note that a full description of the OFS.BULK.MANAGER routine is out of scope in this presentation. If you want to have more details about this, please consult the Open Financial Service training materials.

Temenos University - August 2012

84

AA Technical Framework

1. You can monitor simulations using an enquiry called AA.SIMULATION.MONITOR. 2. The enquiry would tell you the status of any simulation or execution of simulation. What you see here are two simulations, one of which is successful and the other is not, and one successful execution of simulation – which has transformed a simulated record into a LIVE one.

Temenos University - August 2012

85

AA Technical Framework

ACTIVITY.PRESENTATION is a Property Class which allows us to attach specific versions to another Property Class, a Property or an Activity during LIVE updates or simulations. If a conflict between versions arises, the version connected to the most specific level will take precedence (i.e. versions connected to Activities take precedence over Property-specific ones and Property-specific versions take precedence over views associated to a Property Class) Steps involved in associating a Version to an AA Screen are: Create a VERSION record Define a new Product Condition within the ACTIVITY.PRESENTATION property class in which you associate the VERSION to the chosen level Attach the newly created Product Condition to the appropriate Product Proof & Publish

Temenos University - August 2012

86

AA Technical Framework

As anticipated, different Customised Screen Layouts can be triggered based on three different levels: • • •

Property Class Property Activity

In this picture, the different levels are from the least specific (Property Class) to the most specific (Activity). If a conflict arises, the most specific level will take precedence over the least specific one. This means that when different versions are associated to two connected levels, the version associated to the most specific level will take precedence over the other - e.g. if version 1 is associated to the LENDING-DISBURSE-COMMITMENT Activity and version 2 is associated to the COMMITMENT Property, when the LENDING-DISBURSE-COMMITMENT activity takes place, version 1 will be displayed to end-user instead of version 2. We will now see how to set up this through the ACTIVITY.PRESENTATION property class. All the simulated arrangement conditions are stored in an application called AA.ARR.. When you define product conditions for the ACTIVITY.PRESENTATION property class, you should create versions for applications that are prefixed with AA.ARR. (more information about this is available in the AA Basic Customisation course). As you recall, the simulated arrangement conditions are stored in an application prefixed with AA.SIM. - therefore, if we want to create customised screens for simulated activities, we should created versions of the AA.SIM.PROPERTY class and connect them to a specific product through the ACTIVITY.PRESENTATION property class. Please also note that conditions created for the ACTIVITY.PRESENTATION property class will be linked to the PRESENTATION property at the product level. This kind of link can be established on a Parent product record or on a Child product record – in case no PRESENTATION property is defined at the Child level, then the condition set in the Parent’s record will be inherited. If a PRESENTATION’s condition is assigned to both a Parent and a Child product, then the Child’s settings will take precedence over the parent’s. Let’s try to understand this with an example.

Temenos University - August 2012

87

AA Technical Framework

Let’s take a look to the DEPOSIT.18M product within the ‘Term Deposits’ Product Group of the ‘Deposits’ Product Line – we can access this AA.PRODUCT.DESIGNER record through Admin Menu > Product Builder > Products. This product has NO condition defined for the PRESENTATION Property – this means that such condition will be inherited from its parent, product, i.e. DEPOSIT.PARENT.

Temenos University - August 2012

88

AA Technical Framework

Looking at the DEPOSIT.PARENT record in AA.PRODUCT.DESIGNER, we can see that the condition assigned to the PRESENTATION property is ‘DEPOSITS’. In order to check the features of such condition, we can access to AA.PRODUCT.DESIGNER-PRODUCT.CONDITIONS composite screen, via Admin Menu > Product Designer > Product Conditions, and check out the list of Product conditions associated with the ACTIVITY.PRESENTATION property class. ‘DEPOSITS’ is, of course, the product conditions we are looking for.

Temenos University - August 2012

89

AA Technical Framework

Let us take a closer look to the DEPOSITS record in the AA.PRD.DES.ACTIVITY.PRESENTATION application, which defines all product conditions associated with the ACTIVITY.PRESENTATION property class. In this example we are using the AA.PRD.DES.ACTIVITY.PRESENTATION,AA version available under the usual AA.PRODUCT.DESIGNERPRODUCT.CONDITIONS composite screen, so all customised screens used for the DEPOSITS record are listed under the ‘Default Values’ tab. As we can see, this tab is divided in three parts – you first have all screen versions associated with Activities, then customised screens for Properties and finally views associated with Property classes, so from the most specific level to the most generic. If a conflict arises between these three level, the version associated with the most specific level will take precedence over the screen view linked to the most generic level. For example - when we want to change the commitment of a product which refers to the DEPOSITS condition, we may use either the AA.ARR.TERM.AMOUNT,AA version associated with the TERM.AMOUNT property class or the AA.ARR.TERM.AMOUNT,AA .CHANGE.AMOUNT version linked to the DEPOSITS-CHANGE-AMOUNT-COMMITMENT activity, as COMMITMENT is a property derived form the TERM.AMOUNT property class. As the ACTIVITY level is more specific than the PROPERTY.CLASS one, the version displayed to end-users for change of amounts in the commitment screen will be AA.ARR.TERM.AMOUNT,AA .CHANGE.AMOUNT . However, for another activity involving the TERM.AMOUNT property class e.g. LENDING-DISBURSECOMMITMENT, with no activity-specific and no property-specific versions associated with, then the AA.ARR.TERM.AMOUNT,AA version will be used.

Temenos University - August 2012

90

AA Technical Framework

Let us also note that we can associate two versions with each Activity/Property/Property class here listed – one for actual updates on LIVE files (these versions are labeled ‘Activity Versions’) and the other one for SIMULATION purposes (‘Sim Versions’). For instance, when we create a new arrangement for a product using the DEPOSITS product condition in association with the PRESENTATION property, we will be presented with an arrangement screen which presents multiple Properties on the AA.ARRANGEMENT.ACTIVITY,AA screen of the Product Catalog, each and every of them in a separated screen e.g. Account, Arrangement Rules, Commitment etc. In case we want to generate a new LIVE arrangement, the Account Property will rely on the AA.ARR.ACCOUNT,AA.SIMPLE screen view while the AA.SIM.ACCOUNT,AA.SIMPLE version will be presented to users who want to simulate the creation of an arrangement, instead (as we know, this means that the AA.SIM.ACCOUNT application is going to be updates instead of the AA.ARR.ACCOUNT one). Also, when we set up a new LIVE arrangement, the Commitment property will be presented through the AA.ARR.TERM.AMOUNT,AA.SIMPLE.TD version, while the commitment screen used for simulating a new Deposit arrangement will be AA.SIM. TERM.AMOUNT,AA.SIMPLE.TD, instead. And so on and so fort.

Temenos University - August 2012

91

AA Technical Framework

Here we can see what the two versions of the ACCOUNT property used for LIVE updates and for simulations will look like when opened by an end-user during the process of creating a new 18 Months Deposit arrangement. If we want to change the way the Account Property Screen is presented for simulation of DEPOSITS-NEW-ARRANGEMENT we should either update the ‘Sim Version’ connected to this Activity within the DEPOSITS product condition for ACTIVITY.PRESENTATION or create a brand new product condition linked to ACTIVITY.PRESENTATION, and then attach it to our product. Testing on ACTIVITY.PRESENTATION is out of scope for this presentation but you can find more information about this property class within the AA Basic Customisation training course. The Simulation Engine chapter is now completed and we can move to the next topic, i.e. an Overview of the Rules Engine functionality in Toolbox, when applied to the AA module.

Temenos University - August 2012

92

AA Technical Framework

Temenos University - August 2012

93

AA Technical Framework

The Rules Engine is a tool to define and apply business rules which can be used across multiple modules of T24. These business rules are small routines which check conditions based on the contents of specific fields in T24 applications or of system parameters; based on the check output, the rules return specific statuses, output messages, scores and error messages. Business rules set up by the Rules Engine might come from legal regulation (Eg. “KYC legislation requests each new client of a financial institution to supply a valid identification document when they apply for a bank account – if this document is not received within two weeks, the system should through an alert message”), company policy (Eg. "All customers whose credit card monthly balance is over $2000 for 4 month in a row, will receive an increase in their credit card limit"), or other sources.

Temenos University - August 2012

94

AA Technical Framework

• •

•

•

Each business rule is a standalone and can be recycled across multiple modules in T24, multiple work-flows etc. Business rules can only produce knowledge by analysing system data; however a response for such analysis can be only developed through other T24 applications or workflow The rules engine will evaluate and execute rules, which are expressed as ifthen-else statements, without affecting the way T24 applications run – in other words rules can be changed without changing the applications’ source code Rule-based applications communicate with the rule engine by passing in the set of rules to be executed. Each rule is composed of two parts – condition (i.e. parameters checking) and action (i.e. display results or process them further).

Please note that the process of connecting rules to a workflow or attach them to CRM events management is out of the scope of this session. In order to have some more information about this, please refer to the Customer Relationship Management training course.

Temenos University - August 2012

95

AA Technical Framework

The Rules Engine does not have any business logic and the rules it designs can be executed across various modules in T24. The Rules Engine can run on all T24 applications to gather the data required for rules’ conditions. Note that the Rule Engine does not update the application logic but is only used to display data retrieved from T24 files. For example : CUSTOMER, FUNDS.TRANSFER If you are designing a rule for the PROCESS WORKFLOW module, based on the result of the rule, you can proceed to other activities in the process definition. The Rules engine can be executed with CUSTOMER RELATIONSHIP MANAGEMENT to campaign new products to specific customers who have obtained an appropriate status with respect to the rule. When it comes to the Rules engine applied to ARC-IB, you can decide on what needs to be displayed on the screen when a particular customer, who satisfies a rule’s conditions, logs on to Internet Banking.

Temenos University - August 2012

96

AA Technical Framework

Temenos University - August 2012

97

AA Technical Framework

T24 Toolbox is the interface which is used to create rules and attach them to different applications in T24 – in this way they can be re-used across multiple contexts within T24. The Rules engine, as we have learnt, does not have any business logic and cannot store any data – the same applies to all other Toolbox’s functionalities. Toolbox is just used as a T24 user interface – consequently we are going to input our usual T24 login and password to access it. To access the T24 Rules Designer application, we should click on the ‘Designers and Wizards’ tab, which will take us to the ‘Configuration and Customization’ page. Then we will double-click on the Rules Designer icon, which opens as a pop-up the T24 Rules Designer page. In this page we can either create a new rule or open rule that you have saved to T24 or even open a rule that is saved to local machine. When we click on ‘Create a New Rule’, the page where you actually have to write the rule is displayed. The ‘Open Rule from T24’ will open rules which have been already validated and published in T24, while the option ‘Open Rule from Local File’ will open rules that you might have saved on your client laptop (it is sometimes convenient saving on a Local File rather than directly in T24 if you have to stop creating your rule half-way through – in fact rules saved to T24 are subject to validation checks, as we will see, so you would not be entitled to publish to T24 an incomplete or badly-structured rule). Please note that further functionalities of Toolbox are out of scope for this presentation – if you want to know more about this topic, you should refer to the T24 Toolbox-specific training course or user guides.

Temenos University - August 2012

98

AA Technical Framework

We are now on the ‘Start Page’ tab of the T24 Rules Designer screen. When we click on the ‘Create a New Rule’ option, a dialog box will open up for us to input the ID of the new rule and a brief Description. After we have completed this task and clicked on the ‘Ok’ button, we will be redirected to the ‘Designer’ tab of the T24 Rules Designer screen – we are currently designing the AA.TRG.TEST rule, as explained on top of the window on the left-hand side of the screen. The ‘Designer’ tab of the T24 Rules Designer screen is, in fact, where we will write the rule with all the conditions and conventions specific to Rules Engine and either save it to T24 or to the local machine. We will learn now about the various functionalities provided in this screen. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.

14.

The first icon on the application menu can be clicked to open a new page to write a fresh rule. The second is used to open any existing rule which was saved earlier to the local file. The next icon is used to open a rule from T24. The fourth icon is used to save a new rule to the local file. To save the new rule to T24, we can click on the fifth icon. The rules saved to T24 will be stored in the application EB.RULES.VERSION. We will learn about this application as you proceed in the course. If we want to print down the rule, you can use the sixth icon. The seventh icon is used to comment selected lines in the rule while The eighth icon is used to uncomment them The ninth icon is used to increase indent while writing the rule while The tenth icon is used to decrease the indent If you want to edit the description for a rule than you can click on the eleventh icon. The twelfth icon is used to validate the rule, e.g. to test whether it is well-structured and in an acceptable format. The last but one icon is the ‘Test Harness’ icon which is used to test the rule. This is designed to enable the user to test the rule and ensure that it is giving the expected results, before applying it. The user is able to enter sample data without accessing T24 data, to see the output that would be generated if this data was supplied from T24 through the contexts. The last icon is used to deploy all the rules. All the rules deployed will be recorded in a log file in &SAVEDLISTS& with record ID as ARC.RULES.DEPLOYED

Temenos University - August 2012

99

AA Technical Framework

On the top right-hand side of the ‘Designer’ tab, we can see the ‘Rules Toolbox’ menu. All the components required to write a rule are present in this menu. We will learn about each tab and its contents in detail. The ‘Rules Toolbox’ menu has a tree-expandable structure and the first option is labeled ‘CONTEXTS’ – this section of the menu should contain a list of ‘Contexts’, which means records listing one or more applications whose fields can be used to define our rule’s condition. The context can further describe how data should be extracted from the application/s it contains, e.g. via simple selection rules or through a routine. For example, if the CONTEXT record we have selected only refers to the AA.ARRANGEMENT table, we can choose one of the AA.ARRANGEMENT fields to define a condition – e.g. we may want to build a rule which applies to arrangements in US dollars only, so we may build a condition which extracts the data contained in the CURRENCY field of AA.ARRANGEMENTS and checks whether it is equal to USD or not. You might wonder where it is possible to create and update CONTEXT records – whether it is done using the Rules Engine tool or within another T24 interface. This is what we are going to learn next – let us now go back to the ‘Rules Toolbox’ menu. As soon as a new rule is created, when we click on the ‘Context’ option to expand it for the first time, we can see it is empty – it only shows ‘…’ within it. If we click on this content, though, a pop-up window comes up, containing a list of ‘Defined contexts’. This list of ‘Defined contexts’ holds the record IDs of a T24 file called EB.CONTEXT – in fact, in order to make the context records available for use in the Rules Engine, we must set them up in EB.CONTEXT first, through either the GUI or the CUI interfaces of T24 (these kind of updates cannot be carried out directly in Toolbox). In this screenshot, on the bottom right-hand side of the slide, we can see both a list of available EB.CONTEXT records (matching with the ‘Detailed Contexts’ list displayed by the Rules Designer in Toolbox) and a simple EB.CONTEXT record’s content, which enables us to extract fields from the AA.ARRANGEMENT application to define our rule’s condition. As AA.ARRANGEMENT is the only table used within our Context record, it is set as the ‘Primary table’. We will learn more about the structure of the EB.CONTEXT application in the coming slides.

Temenos University - August 2012

100

AA Technical Framework

The ID of the record in EB.CONTEXT can be any user defined alphanumeric text – however T24 checks it to determine which kind of Context we are defining. There can be two types of context records – Simple and Complex. If, when we create a new record, the ID that we have chosen matches with a simple alphanumeric sequence of characters (typically, an existing application name), then T24 will open the new record as a ‘Simple’ Context. If, instead, the record ID follows the structure * (where the first part is, typically, the primary application name), T24 will recognise the new record as a ‘Complex’ Context. The difference between the former and the latter is that a ‘Complex’ EB.CONTEXT record shows more fields as ‘available for updates’ to the end-user. Specifically, simple context records will allow end-user to extract fields from one table and then use these field for defining a rule condition in the Rules Designer, while complex contexts allow access to multiple tables. This implies that Simple ‘EB.CONTEXT’ records will only allow end-users to update the following fields – GB.DESCRIPTION and GB.SHORT.DESC : The fields GB.DESCRIPTION and GB.SHORT.DESC are text field and will hold the description of the context record. PRIMARY.TABLE : The field PRIMARY.TABLE will hold the T24 application name against which the context is based meaning against whose fields the rules is written. If you take a look to the other fields, from LINKED.TABLE to MULTI.VALUE.ACT, they appear as non-editable in this simple context record as they are used only for complex contexts – we will see what they mean in the coming slides. Nota bene: Please remember that only when we have authorised the context record, this will be made available within the T24 Toolbox Rules Designer.

Temenos University - August 2012

101

AA Technical Framework

We will now learn about the complex contexts. This kind of record deals with multiple applications through a drill-down mechanism. In other words, the same EB.CONTEXT record can avail of fields both from its Primary table and of fields belonging to other tables. As previously anticipated, the ID structure of complex contexts record is * where the first part can be a T24 application and the second part can be any meaningful definition based on the purpose of the definition of context record. For example, AA.ARRANGEMENT*CUSTOMER (e.g. a Context which allows you to set up rules for an arrangement also based on the Customer table features). Complex contexts are again of two types – Direct Complex context and Derived Complex context. In case of Direct Complex contexts, you can access data from more than one application. This means that you can still retrieve data from you main T24 application (which is mentioned in the PRIMARY.TABLE field) value being the same you can still access values from different fields in different applications that are defined in the multi value field LINKED.TABLE LINKED.TABLE : This multi-value field contains the ID of any application which can be linked to the one mentioned in the PRIMARY.TABLE. These two fields can never store the same application name. A single rule cannot be applied to two different applications unless they are somehow related (e.g. the LINKED.TABLE is the SYSTEM.REFERENCE.FILE for one of the PRIMARY.TABLE’s fields; or maybe LINKED.TABLE and PRIMARY.TABLE have at least one field in common, e.g. Arrangement ID in case of AA-specific applications). Therefore the value in this field should have some relation to the value in the field PRIMARY.TABLE. Once this Direct Complex EB.CONTEXT record has been authorised, the fields belonging to all the applications stored in PRIMARY.TABLE and LINKED.TABLE will be available under the CONTEXT option in the Rules Designer window.

Temenos University - August 2012

102

AA Technical Framework

The next type of complex context is Derived Complex context which will be used when you cannot access the required data using simple or direct complex contexts. This can be achieved in two ways – Using j-descriptor field and by attaching the routine. DATA.LABEL : The field DATA.LABEL holds the name of the new derived field which can be directly used while writing the rule. LABEL.DESCRIPTI : The description for the variable mentioned in the field DATA.LABEL can be given in the field LABER.DESCRIPTI. DATA.TYPE : The field DATA.TYPE will hold the type of data that the variable mentioned in the field DATA.LABEL can hold. It data type can be text or number or date. SELECTION.PR : The field SELECTION.PR is used as a j-descriptor field which holds the information as to from where the value of the field mentioned in DATA.LABEL is derived from. Syntax is FILE>FIELD>FILE>FIELD In the example displayed by the screenshot on this slide, we can see a context record with ID FUNDS.TRANSFER*AF, relying on FUNDS.TRANSFER as a PRIMARY.TABLE. The SELECTION.PR field is used to extract the Sector of the debited customer, linking the FUNDS.TRANSFER and the CUSTOMER table through the DEBIT.CUSTOMER field on the former application which represents the ID of the latter. The output of this extraction is stored within the DEBIT.SECTOR parameter, defined within the DATA.LABEL field. Once the current EB.CONTEXT record has been authorised, this DEIT.SECTOR field will be made available in T24 Toolbox, when the FUNDS.TRANSFER*AF context is selected in the Rules Engine.

Temenos University - August 2012

103

AA Technical Framework

Alternatively if the required value is very complicated to access (e.g. if you need to extract a part of a compound value or perform some transformation/calculation), you can write a subroutine that will return the required value. DATA.ROUTINE : The field DATA.ROUTINE can hold any valid EB.API routine. The routine mentioned here will be used to derive the value for the variable defined in the field DATA.LABEL. DATA.ARG.TAB and DATA.ARGUMEN : The fields DATA.ARG.TAB and DATA.ARGUMEN form a set of connected multi-value fields where the former stores the ID of the T24 application from which data is passed to the routine and the latter contains the specific field of the application in DATA.ARG.TAB. The field DATA.ARGUMEN can hold either a valid field name or a common variable accessed within T24 like ID.OPERATOR, ID.COMPANY, etc.,. MULTI.VALUE.ACT : The field MULTI.VALUE.ACT will decide what action to perform if in case the returned argument is multi-valued. If nothing is mentioned in this field then always the first value from the output will be taken and sent to the rules engine for processing the rule. The data type mentioned in the field DATA.TYPE will apply to the value derived from both the j-descriptor and routine, in case. In the current slide we can see, as an example, an EB.CONTEXT record where a routine called CALCULATE.AGE is used to calculate the age of a customer based on the DATE.OF.BIRTH field in the CUSTOMER table. The value returned by the routine is stored within the variable DOB (defined in the DATA.LABEL field of the EB.CONTEXT record) and is then presented to user amongst the parameters of the CUSTOMER.AGE context in the T24 Rules Engine.

Temenos University - August 2012

104

AA Technical Framework

The next tab in the Rules Toolbox is the ‘System Variables’ option. Under this sub-menu, all the common variables that can be used while writing a rule are listed. The icons on the left-hand side resemble the data type of that particular variable. All these variables are also pre-defined in the EB.CONTEXT application, in the record SYSTEM. All the system variables that are to be listed under the ‘System variables’ sub-menu, should be stored in this record. The values defined under ‘System variables’ can be accessed by any rule.

Temenos University - August 2012

105

AA Technical Framework

Apart from simple and complex contexts, EB.CONTEXT can also hold another record named SYSTEM. You will now learn the common variables used while creating rules. The first multi value set defines TODAY which gets its value from DATES application and stores the current working day for the company the user is accessing. The second variable is the OPERATING.COMPANY which contains the COMPANY.CODE for the company our user is currently logged in. The third one is the CURRENT.OPERATOR which holds the ID of our user. The fourth value is the LOCAL.COUNTRY.OF.BANK, which gets its content form the last multi value field of LOCAL.COUNTRY field in the COMPANY table. The fifth system variable is the SECOND.WORKING.DAY which calculate the next working day in a company through the EB.CALC.S.W.DAY routine defined in EB.API

Temenos University - August 2012

106

AA Technical Framework

The last four variables are specific to Rules Engine. These variables are used as return variables. RULE.STATUS can be used within the rule to indicate whether or not the rules condition are met meaning passed or failed. RULE.MESSAGE is used to define a response message or narrative for a certain rule’s condition. RULE.SCORE is used within the rule to return a score if a certian condition is met. RULE.ERROR is used to return a string id, for lookup in the EB.ERROR table, if the condition is not met. If you want to add any new variables, you have to multi-value the related fields in this application.

Temenos University - August 2012

107

AA Technical Framework

The ‘Rule Variables’ option is used to create local variables for a particular rule. These variables cannot be used across other rules but are associated only with the currently opened one – if a variable is used while writing a rule but has not been previously defined as a ‘System Variable’ or as a ‘Rule Variables, you will not be able to save the rule. To add a new variable, you need to give the name and a description for the variable and save it. Then these variables can be used in the rule.

Temenos University - August 2012

108

AA Technical Framework

The next option available on the Rules Toolbox menu is ‘Embedded Rules’. This is used to embed the existing rules into a new rule. You can select an existing rule from the list and click on ‘Ok’ button to embed it. If an embedded rule uses a context that is not used by the existing rule, then that context must be added to the existing rule which will be done automatically by T24 Toolbox, which will notify the user through a pop-up message.

Temenos University - August 2012

109

AA Technical Framework

EB.RULES.HIERARCHY is a T24 system-maintained type ‘L’ file which is created or amended whenever a rule record is created or amended via the Toolbox Rules GUI. It shows the link between embedded rules. In this application, there are just two relevant fields 1. HIERARCHY.CHAIN – which shows the chain of embedded rules linked to the underlying rule for which this record is created 2. @ID – This system generated key for EB.RULES.HIERARCHY is the underlying EB.RULES.VERSION rule name and the date the rule was created. Concatenated together forms the unique identifier of the EB.RULES.HIERARCHY file. EB.RULES.VERSION is an application in T24 which keeps track of all the versions of existing rules when they are updated. Together with a rule description, each EB.RULES.VERSION record stores the date in which the new rule’s version was created (which is included in the rule version ID), all the contexts used by a particular version of a rule, the contexts used, the list of rule’s variables with their descriptions, the list of system variables stored in the rule and the content of the rule itself both in text and in xml format. EB.RULES.VERSION is also automatically updated by T24 but, unlike EB.RULES.HIERARCHY, it is a type ‘H’ file which also allows manual updates. EB.RULES.VERSION is linked to another application, namely EB.RULES which stores version dates for all currently valid rules in T24. This file is a type ‘L’ and it is amended only when a rule is generated or updated using T24 Toolbox – no manual change is allowed in this application. IDs in EB.RULES are the Rule IDs themselves and these records only contain descriptive fields regarding the rule and versions avalable. The existence of all applications above is, again, necessary for rules versioning, and through EB.RULES.HIERARCHY the user can work out how the changing of one rule may impact the processing of other rules. For example, if a rule is updated to add a new context, then all rules which use that rule may also need to be updated, to ensure they can still provide the necessary data to run that rule

Temenos University - August 2012

110

AA Technical Framework

The last option available on the Rules Toolbox menu is the ‘Functions’ where all the control statements and operands that can be used while creating rules are defined. If we just double click on any of these statements, they will be pasted on the designer page for you to write the rule. All these are a part of Rule Designer GUI in Toolbox. Apart from the ones listed, you can also use mathematical operators like ‘*’, ‘+’, ‘-’ and ‘\’.

Temenos University - August 2012

111

AA Technical Framework

Temenos University - August 2012

112

AA Technical Framework

Now that you know the components that can be used to write a rule, let us write a simple rule and save it to T24 and see how is the rule executed and how we can achieve a response. The rule we have created here checks relies on the AA.ARRANGEMENT context previously shown on slide 101, which includes fields coming from the AA.ARRANGEMENT table. What the rule does is to select an arrangement and then check the currency of the arrangement. If the currency is USD, then the rule will return the message “USD ARRANGEMENT” else the message displayed will be set to “WRONG CURRENCY”. Before saving the rule, it is a good idea to validate the content of it with the redtick button (‘Validate’ button). If the our rule is well structured, the validation will be successful and Toolbox will prompt us with a pop-up window stating that the ‘Rule is valid!’. Then, we can click on the ‘Save to T24 button’ and – again – when the record is saved a confirmation message appears.

Temenos University - August 2012

113

AA Technical Framework

You can use the test harness option to check if the rule is working the same way it is intended to work without actually inputting values from T24. In the rule that we have used, an error will be thrown if the value CURRENCY from context AA.ARRANGEMENT is not set to USD. Let us try to test the rule by giving some sample data to see the output that would be generated if this data was supplied from T24 through the contexts.

Temenos University - August 2012

114

AA Technical Framework

In the screen shots above the values entered are USD, first, and then GBP. Note that all the variables defined in the rule are getting displayed properly for both the values. Therefore you can now say that the rule will work fine when integrated to T24.

Temenos University - August 2012

115

AA Technical Framework

Now that we are sure that our rule works fine, we would like to finally use the rule to select particular set of arrangements. To achieve this, we should deploy the rule on the AA.ARRANGEMENT application and to get required information from an application – this can be achieved through an enquiry called EB.RULE.CLIENT. Once we input the value AA.ARRANGEMENT in the SELECTION.TABLE field and the ID of our rule (i.e. AA.TEST.CURRENCY) in the RULE.ID field of the enquiry search box, EB.RULE.CLIENT can be run, our rule gets executed and the specified values are returned. Therefore the bank can now take appropriate decision against the arrangements which have passed the rule. Note that the output of the rule can only be used for decision making and will not be stored in the database.

Temenos University - August 2012

116

AA Technical Framework

Which application stores details of all the proofed products? And to what other application are they moved after publishing? AA.PRODUCT.PROOF and AA.PRODUCT.CATALOG What is the name of the AA Publishing service? Is it also used for proofing or not? The TSA.SERVICE record ID of the AA publishing service is BNK/AA.PUBLISH.SERVICE. It is used to both proof and publish products. Do updates on a product condition affect also existing arrangements or only new ones? It depends on whether the property linked to the updated condition is set to TRACKING or not – changes on conditions for TRACKING properties will affect also existing arrangements while updates on NON.TRACKING properties’ conditons will influence only future arrangements. What are the three stages of the Simulation Process and how are they carried out in T24? The three stages of the Simulation Process are – 1) Data capture, which is performed using the AA.SIMULATION.CAPTURE application 2) Simulation Runner, done using the application AA.SIMULATION.RUNNER 3) Simulation service, which is completed by running the BNK/AA.SIMULATION.SERVICE record in TSA.SERVICE What application is used to store details of simulated arrangements? AA.ARRANGEMENT.SIM Which T24 interface should we use to have access to the T24 Rules Designer tool? Toolbox, precisely the ‘Wizard and Enquiry’ session.

Temenos University - August 2012

117

AA Technical Framework

Temenos University - August 2012

118

AA Technical Framework

Temenos University - August 2012

119

AA Technical Framework

Temenos University - August 2012

120