| Question: A consultant is designing a Student Loan Product which belongs to the Personal Loans Product Group. She includes a Loan Account Property which belongs to the Account Property Class and has defined the Arrangement Link as "TRACKING". When committing the Product Designer record, she gets an error "PROPERTY CANNOT BE TRACKED". What could be the possible cause for this error? |
| 1. The Account Property Class is not trackable and therefore the conditions linked to the Loan Account Property cannot be tracked. | 2. The Loan Account Property has been defined as "PRODUCT ONLY". | 3. The Account Property Class has been set as "MANDATORY" in the Personal Loans Product Group. | 4. The attached Product Condition has an effective date greater than today and therfore the Property cannot be set to "TRACKING". | 5. |
| Answer: The Account Property Class is not trackable and therefore the conditions linked to the Loan Account Property cannot be tracked. |
| Question: What is the purpose of setting the REBUILD.ACTIVITIES field to "YES" when committing a Product Group. |
| 1. AA will build/rebuild the Activity records for every Property defined in the Product Group. | 2. AA will build/rebuild the Activity Class records for every Property defined in the Product Group. | 3. AA will build/rebuild all of the Activity records for the every Property Class defined in the Product Group. | 4. AA will build/rebuild the Activity Class records for every Property Class defined in the Product Group. | 5. |
| Answer: AA will build/rebuild the Activity records for every Property defined in the Product Group. |
| Question: Which of the following statements is true? |
| 1. A Property Class defined as 'Mandatory' in a Product Line, should have at least one Property specified at the Product group level. | 2. A Property Class defined as 'optional' in a Product Line, should have at least one Product Condition specified at the Product Group level. | 3. A Property Class defined as 'Optional' in a Product Line, cannot have a Property defined as 'Mandatory' at the Product Group level. | 4. A Property Class defined as 'Mandatory' in a Product Line, can be made 'Optional' at the Product Group level. | 5. |
| Answer: A Property Class defined as 'Mandatory' in a Product Line, should have at least one Property specified at the Product group level. |
| Question: While creating a Product Group, a user gets the following error "AT LEAST ONE PROPERTY MUST BE MANDATORY". What is the reason for this? |
| 1. The user has set the MANDATORY field to 'NO' for all of the Properties belonging to a Property Class which is defined as 'Mandatory' at the Product Line level. | 2. The user has set the MANDATORY field to 'YES' for one of the Properties belonging to a Property Class which is defined as 'Mandatory' at the Product Line level. | 3. The user has set the MANDATORY field to 'YES' for all of the Properties belonging to a Property Class which is defined as 'Mandatory' at the Product Line level. | 4. The user has set the MANDATORY field to 'NO' for one of the Properties belonging to a Property Class which is defined as 'Mandatory' at the Product Line level. | 5. |
| Answer: The user has set the MANDATORY field to 'NO' for all of the Properties belonging to a Property Class which is defined as 'Mandatory' at the Product Line level. |
| Question: Is it possible to create product conditions for the CHARGE property class following format? 1. CHARGE.COND1--20081010 2. CHARGE.COND2-USD-20081010 |
| 1. It is not possible since currency is a mandatory component for all the product conditions of all the property classes | 2. It is not possible since product conditions created for the CHARGE property class need to have currency as part of their ID. | 3. It is possible since currency is an optional component for the CHARGE product condition. | 4. It is possible because both currency and date are optional components for the CHARGE product condition. | 5. |
| Answer: It is possible since currency is an optional component for the CHARGE product condition. |
| Question: A Personal Loan Product is available for sale in the Product Catalog. When inputting an arrangement for the product, the user specifies the currency as JPY. When validating the activity the user gets the following error "NOT A VALID CURRENCY FOR THIS PRODUCT ". What is the reason for this? |
| 1. JPY is not defined in the CURRENCY file of T24. | 2. JPY is not defined a valid currency in AA.PRODUCT.DESIGNER(hence not propagated to AA.PRODUCT.CATALOG record) for the Personal Loan Product. | 3. JPY is not defined a valid currency in AA.PRODUCT for the Personal Loan Product. | 4. Arrangements can only be entered in local currency. | 5. |
| Answer: JPY is not defined a valid currency in AA.PRODUCT.DESIGNER(hence not propagated to AA.PRODUCT.CATALOG record) for the Personal Loan Product. |
| Question: The following is a Product Condition for the Term Amount Property Class: Attribute.1: TERM Options.1: NEGOTIABLE Type.1: MAXPERIOD Value.1: 7Y Message.1: ERROR Attribute.2 : REVOLVING Options.2 : OVERRIDE Default Negotiable : NO Which of the following is a correct statement? |
| 1. While inputting an Arrangement, an Error will be displayed if the TERM entered is greater than 7Y and an Override will be displayed if the REVOLVING field is negotiated | 2. This is an incorrect definition. For the Attribute REVOLVING, OVERRIDE is an invalid option when Default Negotiable is NO | 3. While inputting an Arrangement, an Error will be displayed if the TERM entered is less than 7Y and an Override will be displayed if the REVOLVING field is left blank | 4. While inputting an Arrangement, an Error will be displayed if the AMOUNT entered is less than 100000 and an Override will be displayed if the AMOUNT entered is greater than 1000. | 5. |
| Answer: This is an incorrect definition. For the Attribute REVOLVING, OVERRIDE is an invalid option when Default Negotiable is NO |
| Question: The following is a Product Condition for the Term Amount Property Class: Default Negotiable: YES Attribute.1: AMOUNT Options.1: NEGOTIABLE Attribute.2: REVOLVING Options.2: NON-NEGOTIABLE Which of the following is a correct statement? |
| 1. All fields of the Term Amount Product Condition can be negotiated at the Arrangement level except for the REVOLVING field. | 2. Only the AMOUNT field of the Term Amount Product Condition can be negotiated at the Arrangement level. | 3. All fields except REVOLVING can be negotiated in the Term Amount Product Condition | 4. Only the AMOUNT field can be negotiatied in the Term Amount Product Condition | 5. |
| Answer: All fields of the Term Amount Product Condition can be negotiated at the Arrangement level except for the REVOLVING field. |
| Question: A user creates a new Product Condition for the Interest Property Class. The record ID is DEFAULT.INTEREST-USD-20110310. Where can the user find this record? |
| 1. AA.PRD.DES.INTEREST | 2. AA.ARR.AC.GROUP.INTEREST | 3. AA.PRD.CAT.INTEREST | 4. AA.PRD.PRF.INTEREST | 5. |
| Answer: AA.PRD.DES.INTEREST |
| Question: The following is a portion of a Personal Loan Product Designer record: Property.1: PRINCIPALINT Condition.1.1: PERIODIC.RATE.MARGIN Effective.1.1: Arr Link.1.1: TRACKING Condition.1.2: FIXED.FLOATING.LEVEL Effective.1.2: 1M Arr Link.1.2: TRACKING The following two "PERIODIC.RATE.MARGIN" Product Condition records exist: 1. PERIODIC.RATE.MARGIN-USD-20000101 2. PERIODIC.RATE.MARGIN-USD-20000601 The following two "FIXED.FLOATING.LEVEL" Product Condition records exist: 1. FIXED.FLOATING.LEVEL-USD-20000101 2. FIXED.FLOATING.LEVEL-USD-20000601 For an arrangement input on 1st April 2000, which Product Condition will be effective on 2nd June 2000? |
| 1. FIXED.FLOATING.LEVEL-USD-20000601 | 2. PERIODIC.RATE.MARGIN-USD-20000601 | 3. FIXED.FLOATING.LEVEL-USD-20000101 | 4. PERIODIC.RATE.MARGIN-USD-20000101 | 5. |
| Answer: FIXED.FLOATING.LEVEL-USD-20000601 |
| Question: The following is a Product Condition for the Term Amount Property Class: Attribute.1: AMOUNT Options.1: NEGOTIABLE Type.1.1: MAXIMUM Value.1.1: 100000 Message.1.1: ERROR Type.1.2: MINIMUM Value.1.2: 1000 Message.1.2: OVERRIDE Which of the following is a correct statement?" |
| 1. While inputting an Arrangement, an Error will be displayed if the AMOUNT entered is greater than 100000 and an Override will be displayed if the AMOUNT entered is less than 1000. | 2. While inputting an Arrangement, an Override will be displayed if the AMOUNT entered is greater than 100000 and an Error will be displayed if the AMOUNT entered is less than 1000. | 3. While inputting an Arrangement, an Error will be displayed if the AMOUNT is negotiated. Otherwise an Override will be displayed informing the user that the AMOUNT has not been negotiated. | 4. While inputting an Arrangement, an Error will be displayed if the AMOUNT entered is less than 100000 and an Override will be displayed if the AMOUNT entered is greater than 1000. | 5. |
| Answer: While inputting an Arrangement, an Error will be displayed if the AMOUNT entered is greater than 100000 and an Override will be displayed if the AMOUNT entered is less than 1000. |
| Question: A user inputs anArrangement for the Personal Loan product.. Which application stores values for the fields AMOUNT, TERM, etc. which belong to the Term Amount Property Class for the given arrangement? |
| 1. AA.ARR.TERM.AMOUNT | 2. AA.PRD.PRF.TERM.AMOUNT | 3. AA.PRD.DES.TERM.AMOUNT | 4. AA.PRD.CAT.TERM.AMOUNT | 5. AA.SIM.TERM.AMOUNT |
| Answer: AA.ARR.TERM.AMOUNT |
| Question: Which application would provide the details of last activity triggered on a arrangement? |
| 1. AA.ACTIVITY.HISTORY | 2. AA.ARRANGEMENT.ACTIVITY | 3. AA.ACTIVITY.LOG | 4. AA.ACTIVITY.CLASS | 5. |
| Answer: AA.ACTIVITY.HISTORY |
| Question: Which of the following is user definable in AA? |
| 1. Product Group | 2. Property | 3. Product Condition | 4. Activity | 5. All of the above |
| Answer: All of the above |
| Question: Which application is used to store all the information about product lines? |
| 1. AA.PRODUCT.LINE | 2. AA.PRD.DES.LINE | 3. AA.PRODUCT.GROUP | 4. AA.ARR.PRODUCT.LINE | 5. None of the above |
| Answer: AA.PRODUCT.LINE |
| Question: A property needs to be defined as part of the product - but should not be visible to the user at the arrangement nor should any activity be allowed for this property. How can this be achieved? |
| 1. Set PROPERTY.RESTRICTION field for a property to PRODUCT.ONLY | 2. Set PRODUCT.ONLY field for a property to true | 3. Set PROPERTY.TYPE field for a property to PRODUCT.ONLY | 4. Set PROPERTY.TYPE field for a property to PRODUCT | 5. This cannot be done |
| Answer: Set PROPERTY.TYPE field for a property to PRODUCT.ONLY |
| Question: What is true about currency specific Product Conditions? |
| 1. A currency specific Product Condition can be created only for the local currency. | 2. You cannot manually specify a currency as part of the ID while creating a Product Condition. | 3. Product condition could be defined in any permissible currency but, if the currency is not stated, it automatically defaults to the local currency. | 4. If the currency is defined in the Product Condition ID, then a date cannot be part of the ID. | 5. |
| Answer: Product condition could be defined in any permissible currency but, if the currency is not stated, it automatically defaults to the local currency. |
| Question: At any given point of time how many Product Conditions are applied for a Property of an Arrangement. |
| 1. Two | 2. Three | 3. Any number | 4. One | 5. Product Conditions are attached to Property Classes and not to Properties. |
| Answer: One |
| Question: In which application can we find out whether a given Property Class has been defined as mandatory for a product? |
| 1. Product Condition | 2. Product Group | 3. Product Line | 4. Product | 5. |
| Answer: Product Line |
| Question: Where can the User define a Property as mandatory for a Product? |
| 1. Product Condition | 2. Product Group | 3. Product Line | 4. Product | 5. |
| Answer: Product Group |
| Question: A bank has introduced a new Mortgage Product. One of the bank's customers is interested in it and wants to know the payment amount, based on a negotiated interest rate, before entering into a agreement with the bank. Can this be done in AA? |
| 1. It is not possible. | 2. The bank can simulate a new arrangement. | 3. It is not possible since only live arrangements can be created. | 4. It is not possible since simulation is possible only for activities other than new arrangement. | 5. It is not possible, though a new arrangement can be simulated, interest rate cannot be negotiated. |
| Answer: The bank can simulate a new arrangement. |
| Question: A user inputs a backdated activity for an Internet Service Arrangement. To his surprise he notices that no activities are reversed or replayed. What is the reason for this? |
| 1. Reverse and replay for the Product was not opted by the user | 2. AA does not support reversal and replay of activities. | 3. Reverse / Replay is not supported for Products belonging to the Internet Services Product Line. | 4. A user cannot input backdated activities in AA. | 5. Only the forward dated activites are replayed. |
| Answer: Reverse / Replay is not supported for Products belonging to the Internet Services Product Line. |
| Question: Which application allows the user to initiate simulation in AA? |
| 1. AA.ARRANGEMENT.ACTIVITY | 2. AA.SIMULATION.CAPTURE | 3. AA.SIM.ARRANGEMENT | 4. AA.$SIM.ARRANGEMENT | 5. AA.SIM$.ARRANGEMENT |
| Answer: AA.SIMULATION.CAPTURE |
| Question: A customer wants to negotiate the interest rate of a loan product and to understand the effect of a commitment increase. The user understands that he needs to simulate two activities (change interest and increase commitment) as part of one scenario. How can this be achieved? |
| 1. This is not possible since only one activity can be simulated at any given time. | 2. The user can define the Increase Commitment Activity as a related activity of the Change Interest Activity. | 3. The user must first capture both Activities using AA.SIMULATION.CAPTURE. He can then create a AA.SIMULATION.RUNNER record and reference the IDs of the two captured activities. | 4. It is not possible since Increase Commitment Activity cannot be simulated. | 5. It is not possible since Change Interest Activity cannot be simulated. |
| Answer: The user must first capture both Activities using AA.SIMULATION.CAPTURE. He can then create a AA.SIMULATION.RUNNER record and reference the IDs of the two captured activities. |
| Question: Which Product Lines are not pre-defined by Temenos? |
| 1. ACCOUNTS, DEPOSITS and LENDING | 2. INTERNET.SERVICES and PROXY.SERVICES | 3. OTHER and PROXY.SERVICES | 4. All Product Lines are pre-defined. They are not user definable | 5. No Product Lines are pre-defined. They are all user definable |
| Answer: All Product Lines are pre-defined. They are not user definable |
| Question: Which of the following Product Groups cannot be created by the user? |
| 1. Product Groups containing a "#" value in their ID | 2. Product Groups cannot be created for the Product Line "OTHER" | 3. Product Groups are released by Temenos. Product Groups cannot be created by users. | 4. Any Product Group can be created. None are hard coded | 5. |
| Answer: Any Product Group can be created. None are hard coded |
| Question: How are Product Groups linked to Product Lines in AA.PRODUCT.GROUP? |
| 1. Product Groups are not linked to a Product | 2. Id of Product Group forms part of the id of Product. | 3. Through the PRODUCT.LINE field in AA.PRODUCT.GROUP | 4. Any Product Group which uses the Property Class of a Product Line is automatically linked to the line | 5. By specifying a value of "INTERNAL" in the GROUP.TYPE field in AA.PRODUCT.GROUP. |
| Answer: Through the PRODUCT.LINE field in AA.PRODUCT.GROUP |
| Question: A bank would like to create a base Product and pass on the characteristics of the properties to its child products. The base Product should not be sold to the customers. How can a bank achieve this? |
| 1. The base Product should be marked as "Inheritance Only" | 2. The base Product should be marked as 'Yes' for a Default product | 3. Not possible, all products created should be sold to the customers | 4. Another product should be duly indicated as its Parent | 5. The base product should not be published |
| Answer: The base Product should be marked as "Inheritance Only" |
| Question: How can a bank create a Retail Account Product in AA which could be available in all currencies? |
| 1. By default all the products are available in all currencies | 2. By indicating a value of ALL in the CURRENCY field of the Product Designer | 3. By indicating the desired currencies in multi- value field CURRENCY of the Product Designer | 4. By marking LINE.ATTRIBUTE as CCY in ACCOUNTS Product Line | 5. |
| Answer: By indicating the desired currencies in multi- value field CURRENCY of the Product Designer |
| Question: A bank creates a Product called "Home Loan" but does not assign conditions to a mandatory Property in the group. But the product is successfully proofed and published. What could be the reason? |
| 1. If the "Home Loan" Product has inherited the mandatory conditions from a Parent Product, then this would be possible | 2. During proofing, this Property will become optional | 3. If the mandatory Property is specified as Non-Tracking, then this will be possible | 4. If the mandatory Property is specified as Tracking, then this will be possible | 5. |
| Answer: If the "Home Loan" Product has inherited the mandatory conditions from a Parent Product, then this would be possible |
| Question: What happens when arrangement link is set to "CUSTOM TRACKING" for a product condition in a product? |
| 1. Those attributes that were negotiated or set as FIX-VALUE remain fixed at the arrangement and rest of the attributes track the changes at the product condition. | 2. Those attributes that were negotiated at the arrangement will track changes at the product condition and rest of the attributes remain fixed | 3. Any subsequent changes to the product conditions will be automatically applied to all existing arrangements irrespective of negotiations at the arrangement | 4. Any subsequent changes to the product conditions will not affect existing arrangements | 5. |
| Answer: Those attributes that were negotiated or set as FIX-VALUE remain fixed at the arrangement and rest of the attributes track the changes at the product condition. |
| Question: Is it possible to include more than one Property of a INTEREST Property Class in a Product? |
| 1. Yes, since the TYPE of the Property Class has been defined as MULTIPLE | 2. Yes, since the TYPE of the Property Class has been defined as DATED | 3. This is not possible since only one property can be attached to a INTEREST property class. | 4. This is not since the TYPE of the Property class has been defined as TRACKING | 5. |
| Answer: Yes, since the TYPE of the Property Class has been defined as MULTIPLE |
| Question: The ACCOUNT Property Class is defined as mandatory in the LENDING record of AA.PRODUCT.LINE. What effect does this have on Product Groups? |
| 1. It is not possible for a Property Class to be specified as mandatory in AA.PRODUCT.LINE | 2. At least one Property of the ACCOUNT Property Class has to be included in a Product Group that is linked to the LENDING Product Line | 3. All Properties of the ACCOUNT Property Class have to be included in all Product Groups linked to LENDING Product Line | 4. This has no effect on AA.PRODUCT.GROUP as the rule is meant only for AA.PRODUCT.LINE | 5. |
| Answer: At least one Property of the ACCOUNT Property Class has to be included in a Product Group that is linked to the LENDING Product Line |
| Question: How many balances can an Arrangement of a financial product have ? |
| 1. One for each Property. | 2. Depends on the balance prefix for the associated properties. | 3. One for each Property Class. | 4. One for each Product Condition. | 5. |
| Answer: Depends on the balance prefix for the associated properties. |
| Question: The bank would like to create a number of products which are very similar and only differ in some features. What should you advise? |
| 1. Create a single parent product and multiple child products. Place the common conditions in the parent product and define properties with unique conditions in the child products | 2. Create a single parent product with the common conditions and a single child product with negotiation rules to allow minor changes at the arrangement level | 3. Create a single product with negotiation rules to allow minor changes at the Arrangement level | 4. Create a single product, and multivalue the product conditions within the product to create the variations required | 5. |
| Answer: Create a single parent product and multiple child products. Place the common conditions in the parent product and define properties with unique conditions in the child products |
| Question: The bank wishes to reorganise the structure of the Product Catalog (in the model bank screen view). Specifically, they would like to combine the Internet Services and Proxy Services Product Groups and display them as one single classification in the catalog instead of 2 separate classifications. Is this possible ? |
| 1. Not possible, this is only possible for Product Groups in the OTHER Product Line. | 2. Set the same value in ATTRIBUTE field of the Product Groups | 3. Not possible, the Product Catalog structure must reflect the Product Groups | 4. Modify the PRODUCT.LINE field in the Product Groups. | 5. Recreate the Product Groups in the OTHER Product Line and move the products across by modifying their PRODUCT.GROUP field |
| Answer: Set the same value in ATTRIBUTE field of the Product Groups |
| Question: Which of the following is true about the Effective Date for a Product Condition? |
| 1. It is optional for certain Property Classes | 2. Product Conditions cannot be created with an Effective date in the past | 3. The product must have a product condition for each property with an effective date no later than the Availablity Date | 4. All product conditions for a Product must have the same effective date | 5. |
| Answer: The product must have a product condition for each property with an effective date no later than the Availablity Date |
| Question: A new product has an INTEREST property linked to a Product Condition called SINGLE. There are two product conditions called SINGLE one dated 15 July 2011, the other dated 5th August 2011. I proof and publish this product with an available date of 1 August 2011. Today's date is 23rd July 2011. What happens? |
| 1. Product is published and will be available from 1 August 2011 | 2. Product fails to proof | 3. Product proofs but fails to publish | 4. Product is published and becomes available immediately | 5. Product is published and will be available from 5 August 2011 |
| Answer: Product is published and will be available from 1 August 2011 |
| Question: A new product has an ACCOUNT property linked to a Product Condition called SAVER. There are two product conditions named SAVER - one is dated 29th July, the other is dated 5th September. I proof and publish this product with an available date of 23rd July. Today's date is 15th July. What happens? |
| 1. Product is published and will be available from 23rd July | 2. Product fails to proof | 3. Product proofs but fails to publish | 4. Product is published and will be available from 29th July | 5. Product is published and will be available from 5th September |
| Answer: Product fails to proof |
| Question: Which of the following is not true about the Availability Date used in proofing and publishing a product? |
| 1. It is the earliest date for which an Arrangement can be created for this product | 2. It is when the Product first appears in the Product Catalog | 3. The product must have a product condition for each property with an effective date no later than the Availablity Date | 4. The effective date of a product condition must be later than the date on which the product is published | 5. It is mandatory when Proofing |
| Answer: The effective date of a product condition must be later than the date on which the product is published |
| Question: A user would has created a new Property to be used in a product. Where should the user first attach this property to be effected on the product? |
| 1. Product | 2. Product Group | 3. Product Line | 4. Property Class | 5. Not possible, Properties are created by Temenos |
| Answer: Product Group |
| Question: A user would like to include a new Property of a Property Class in a product. The product already contains another property of the same property class. Which attribute controls whether this is possible? |
| 1. Property Class TYPE field must be set to MULTIPLE | 2. Product Group ATTRIBUTE field must be set to MULTIPLE | 3. Product Line LINE.ATTRIBUTE field must be set to MULTIPLE | 4. Property PROPERTY.TYPE field must not be set PRODUCT.ONLY | 5. Not possible, Properties are created by Temenos |
| Answer: Property Class TYPE field must be set to MULTIPLE |
| Question: A Bank would like to design a Loan Product wherein both Principal Interest and Penalty Interest are levied on the customers. The rate and balances at which these interests are calculated are different. How can this be designed in AA? |
| 1. Create two properties for interest. Attach different product conditions for each of these properties in the product and attach corresponding balances in AA.PRODUCT.DESIGNER for each of these properties. | 2. Interest property cannot be created in multiples | 3. Create two properties for interest and attach the same product condition for both the properties. | 4. Create one property for Interest and attach two different product conditions and attach corresponding balances in AA.PRODUCT.DESIGNER for each of these properties. | 5. |
| Answer: Create two properties for interest. Attach different product conditions for each of these properties in the product and attach corresponding balances in AA.PRODUCT.DESIGNER for each of these properties. |
| Question: A consultant onsite tries to add a ACTIVITY.CHARGE Property to an INTERNET.SERVICES Product Group but this causes an error. What can they do to rectify this? |
| 1. Add the ACTIVITY.CHARGE Property Class to the INTERNET.SERVICES Product Line | 2. Add the ACTIVITY.CHARGE Property to the INTERNET.SERVICES Product Line | 3. It is not possible to configure this as it is not supported by the INTERNET.SERVICES Product Line | 4. Create a new Product Line, and include the ACTIVITY.CHARGE Property Class in this Product Line | 5. Set the PROPERTY.TYPE attribute in the Property to PRODUCT.ONLY |
| Answer: It is not possible to configure this as it is not supported by the INTERNET.SERVICES Product Line |
| Question: A consultant creates a new Property. What additional new configuration data can then be associated with that Property? |
| 1. Activities only | 2. Activities, Activity Classes and Property Classes | 3. Activities and balance types if any balance prefix is defined | 4. Property Classes and Activity Classes only | 5. Property Classes only |
| Answer: Activities and balance types if any balance prefix is defined |
| Question: Among the following property classes, choose the one in which the child product condition does not merge with the parent product condition . |
| 1. ACCOUNTING | 2. ACCOUNT | 3. ACTIVITY.PRESENTATION | 4. ACTIVITY.MESSAGING | 5. ACTIVITY.API |
| Answer: ACCOUNT |
| Question: A user tries to run a simulation but gets a pop-up window saying "Processing…" which does not stop. What could the problem be? |
| 1. The simulation service is not running | 2. There is an error in the Simulation Capture record | 3. There is an error in the Simulation Runner record | 4. The Simulation Capture has been entered but a simulation Runner record has not been created | 5. The Simulation Runner has been entered but a Simulation Capture record has not been created |
| Answer: The simulation service is not running |
| Question: Product condition for interest property in a product is set as "NON.TRACKING". The interest rate at the product is set as 10% and changed to 20% at Arrangement. There is a CHANGE.PRODUCT scheduled in 3 Months and the Interest in that product is configured to 12.5%. Assuming all conditions have DEFAULT.ATTR.OPTION set to "RESETTING" what would be the rate on the arrangement after 3 months? |
| 1. Interest rate stays at 10% | 2. Interest rate stays at 20% | 3. Interest rate resets to 12.5% | 4. An error message is produced for the configuration in AA.PRODUCT.DESIGNER | 5. |
| Answer: Interest rate resets to 12.5% |
| Question: Can a bank user choose to publish a product through a service? |
| 1. Yes it is possible by running the service AA.SIMULATION.SERVICE with process method as SERVICE | 2. Yes it is possible by running the service AA.PROOF.SERVICE | 3. Yes it is possible by running the service AA.PUBLISH.SERVICE with process method as SERVICE | 4. Yes it is possible by running the service AA.PUBLISH.SERVICE with process method as ONLINE | 5. |
| Answer: Yes it is possible by running the service AA.PUBLISH.SERVICE with process method as SERVICE |
| Question: A bank wants to define Special Term Deposits, wherein, the Deposit amount is flexible and does not follow any default amount. Is this possible to be set under Term Amount product condition? |
| 1. The AMOUNT field should be left blank so that no value is defaulted at the Arrangement level and the attribute should be set as Negotiable | 2. The AMOUNT field should be left blank so that no value is defaulted at the Arrangement level and the attribute should be set as Non-Negotiable | 3. The AMOUNT field should have a default value and the DEFAULT.NEGOTIABLE field should be set to No so that no amount is defaulted | 4. It is not possible to set such a condition | 5. The AMOUNT field should have no default value. Additionally, it should be set as Non-Negotiable and to produce an Override message |
| Answer: The AMOUNT field should be left blank so that no value is defaulted at the Arrangement level and the attribute should be set as Negotiable |
| Question: A bank wishes to offer a "Preferential Deposit" Product and its commitment amount must be 500,000. How can this be specified in Term Amount product condition? |
| 1. The AMOUNT field should have a default value of 500,000 and be set as Non-Negotiable | 2. This cannot be set as it is possible for the Deposit to be offered in different currencies | 3. AMOUNT Attribute should be set as Non-Negotiable with a Comparison type of EQUAL and Value of 500,000 | 4. AMOUNT Attribute should be set as Negotiable with a Comparison type of EQUAL and Value of 500,000 | 5. AMOUNT Attribute should be set as Negotiable with a Comparison type of UNEQUAL and Value of 500,000 |
| Answer: The AMOUNT field should have a default value of 500,000 and be set as Non-Negotiable |
| Question: A bank wishes to offer "High Value Deposits" which would not be allowed to be negotiated above 5 million at the Arrangement level. How can this be specified in Term Amount product condition? |
| 1. The AMOUNT field may be defined with a default value of 5 million and set as Non-Negotiable | 2. The AMOUNT field may be defined with no default value and set as Non-Negotiable | 3. The AMOUNT field may be defined with no default value and set to Negotiable upto a MINIMUM of 5 million below which it should be set to generate an Override message | 4. The AMOUNT field may be defined with a default value and set to Negotiable upto a MAXIMUM of 5 million beyond which it should be set to generate an Override message | 5. The AMOUNT field may be defined with an optional default value upto 5 million and set to Negotiable upto a MAXIMUM of 5 million beyond which it should be set to generate an Error message |
| Answer: The AMOUNT field may be defined with an optional default value upto 5 million and set to Negotiable upto a MAXIMUM of 5 million beyond which it should be set to generate an Error message |
| Question: A bank wants to display an Override message if the default value of an attribute is amended at the arrangement level. How should it go about setting this condition? |
| 1. It cannot. The default value of an attribute cannot be amended at the arrangement level | 2. For the appropriate attribute, NR.MESSAGE should be set to 'OVERRIDE' | 3. For the appropriate attribute, NR.MESSAGE should be set to 'ERROR' | 4. For the appropriate attribute, NR.OPTIONS should be set to 'OVERRIDE' | 5. For the appropriate attribute, NR.OPTIONS should be set to 'MANDATORY' |
| Answer: For the appropriate attribute, NR.OPTIONS should be set to 'OVERRIDE' |
| Question: A Property Class has CCY set in its TYPE field. While creating a Product Condition, what happens if currency is not explicitly specified as part of the Id? |
| 1. The currency part of the Id is automatically defaulted to local currency | 2. The date part of the Id is automatically defaulted to local currency | 3. The Product Condition cannot be committed | 4. T24 will prompt the user for a currency | 5. The currency part of the Id is automatically defaulted to Arrangement Currency |
| Answer: The currency part of the Id is automatically defaulted to local currency |
| Question: While creating a Product Condition for the Term Amount Property Class the user enters a record Id without a date. What will be the effect? |
| 1. The condition will be created without a date | 2. Since a date is mandatory for the Term Amount Property Class, the user will encounter error when trying to commit the record | 3. The date part of the record Id is automatically defaulted to system date | 4. An error will occur when proofing a Product with this Product Condition | 5. The date part of the record Id is automatically defaulted to the Arrangement date |
| Answer: The date part of the record Id is automatically defaulted to system date |
| Question: A bank only deals with USD which is also its local currency. A definition exists in CHARGE product condition and a currency has not been stated in the key of this condition (e.g. ADMINCHARGE--20130101) . What is the effect of this on the CURRENCY field of the Charge condition? |
| 1. The CURRENCY field is defaulted with the local currency (i.e. USD) | 2. The CURRENCY field must be populated, however the currency specified in this field can be different from the currency defined in Id | 3. The CURRENCY field is defaulted with the currency defined in Id | 4. Only charge dealing with USD may be stated in this condition and no other currency would be allowed | 5. |
| Answer: The CURRENCY field must be populated, however the currency specified in this field can be different from the currency defined in Id |
| Question: What are Periodic Rules? |
| 1. Rules that apply only to PERIODIC.CHARGES property. | 2. Rules for governing periodic interest rates | 3. Rules placed on attributes that have a time element | 4. Rules that can be applied daily, weekly, monthly or annually | 5. Rules that determine the frequency of scheduled activities |
| Answer: Rules placed on attributes that have a time element |
| Question: The Arrangement Overview displays the full Schedule of payments(with dates, amount etc till the end of the schedule) for an Arrangement. In which table is the data for this stored? |
| 1. AA.SCHEDULE.DETAILS | 2. AA.DETAILS.SCHEDULE | 3. AA.SCHEDULED.ACTIVITY | 4. AA.ARR.PAYMENT.SCHEDULE | 5. It is not stored anywhere, they are projected and computed at run time by a NOFILE enquiry |
| Answer: It is not stored anywhere, they are projected and computed at run time by a NOFILE enquiry |
| Question: Which of the following is not true about the Availability Date used in proofing and publishing a product? |
| 1. It is the earliest date for which an Arrangement can be created for this product | 2. It is when the Product first appears in the Product Catalog | 3. The product must have a product condition for each property with an effective date no later than the Availablity Date | 4. It must be later than or equal to the date on which the product is published | 5. It is mandatory when Proofing |
| Answer: It must be later than or equal to the date on which the product is published |
| Question: Where can a bank define a Negotiation Rule Attribute for use with a Product Condition? |
| 1. A Negotiation Rule Attribute is any valid field name in the respective property class and that could be defined directly in the product condition. | 2. A Negotiation Rule Attribute can be defined by creating a valid record in AA.PROPERTY.CLASS, as attributes are derived from respective Property Class | 3. A Negotiation Rule Attribute can be defined by creating a valid record in AA.PROPERTY | 4. A Negotiation Rule Attribute can be defined by creating a valid record in AA.PRODUCT.LINE, as attributes are derived from respective Property Classes | 5. |
| Answer: A Negotiation Rule Attribute is any valid field name in the respective property class and that could be defined directly in the product condition. |
| Question: A bank wishes to create a Product Condition which allows for negotiation of certain attributes at Arrangement level while some other fields should be non-negotiable. How should it go about creating this condition if it has decided to set the DEFAULT.NEGOTIABLE field to Yes? |
| 1. It should specify the fields that are Non-Negotiable and must specify default values for any of these fields which are mandatory. For Negotiable fields the bank can optionally define default values and any necessary negotiation rules | 2. It should specify the fields that are Non-Negotiable and optionally specify default values for any of these fields which are mandatory. For Negotiable fields the bank must define default values and any necessary negotiation rules | 3. It is not possible to set the DEFAULT.NEGOTIABLE field as Yes when there are Negotiable fields | 4. It is not possible to set the DEFAULT.NEGOTIABLE field as Yes when there are Non Negotiable fields | 5. |
| Answer: It should specify the fields that are Non-Negotiable and must specify default values for any of these fields which are mandatory. For Negotiable fields the bank can optionally define default values and any necessary negotiation rules |
| Question: A bank wishes to offer "High value Deposits" but wants a warning if the deposit amount goes above 2 million at the Arrangement level. How can this be specified in the Product condition? |
| 1. The AMOUNT attribute to be defined with a default value of 2 million and set to Non-Negotiable | 2. The AMOUNT field to be defined with an optional value upto 2 million and set to Negotiable upto a MAXIMUM of 2 million beyond which it should generate an Error message | 3. The AMOUNT field may be defined with no default value and set to Negotiable upto a MAXIMUM of 2 million above which it should be set to generate an Override message | 4. The AMOUNT field to be defined with a default value of 2 million and set Default Negotiable to NO | 5. |
| Answer: The AMOUNT field may be defined with no default value and set to Negotiable upto a MAXIMUM of 2 million above which it should be set to generate an Override message |
| Question: A bank wishes to offer "Housing Loans" which generally have a Term of 5 Years or more. In certain cases the bank wishes to approve an arrangement which is less than 5 years. How can this be specified in the Product condition? |
| 1. This cannot be set up | 2. The TERM field should be defined with no default value and set as Negotiable with a MINPERIOD of 5Y, below which it should generate an Error message | 3. The TERM field should be defined with no default value and set as Negotiable with a MINIMUM of 5Y, below which it should generate an Error message | 4. The TERM field should be defined with an optional default value of 5Y or above and set as Negotiable with a MINPERIOD of 5Y, below which it should generate an Override message | 5. |
| Answer: The TERM field should be defined with an optional default value of 5Y or above and set as Negotiable with a MINPERIOD of 5Y, below which it should generate an Override message |
| Question: A Property can be hidden to prevent users from modifying or viewing the attributes at the arrangement level. How is this achieved? |
| 1. For such a Property, the PROPERTY.TYPE in AA.PROPERTY should be set to 'SUSPEND' | 2. For such a Property, the PROPERTY.TYPE in AA.PROPERTY should be left blank | 3. For such a Property, the PROPERTY.TYPE in AA.PROPERTY should be set to 'PRODUCT.ONLY' | 4. This is not possible as a Property belonging to an arrangement can never be hidden | 5. |
| Answer: For such a Property, the PROPERTY.TYPE in AA.PROPERTY should be set to 'PRODUCT.ONLY' |
| Question: A bank wants to display an Override message if the default value of an attribute is amended at the arrangement level. How should it go about setting this condition? |
| 1. It cannot. The default value of an attribute cannot be amended at the arrangement level | 2. For the appropriate attribute, NR.MESSAGE should be set to 'OVERRIDE' | 3. For the appropriate attribute, NR.MESSAGE should be set to 'ERROR' | 4. For the appropriate attribute, NR.OPTIONS should be set to 'OVERRIDE' | 5. For the appropriate attribute, NR.OPTIONS should be set to 'MANDATORY' |
| Answer: For the appropriate attribute, NR.OPTIONS should be set to 'OVERRIDE' |
| Question: Which Activity is generated by the system when AA sends a message for Delivery? |
| 1. Issue Advice | 2. Issue Notice | 3. Activity Message | 4. Issue Message | 5. No Activity is generated |
| Answer: No Activity is generated |
| Question: Which application must the user enter to calculate a payoff? |
| 1. AA.ARRANGEMENT.ACTIVITY | 2. AA.SIMULATION.CAPTURE | 3. AA.ARR.PAYOFF | 4. AA.ACTIVITY | 5. AA.ARRANGEMENT |
| Answer: AA.SIMULATION.CAPTURE |
| Question: A bank wishes to have multiple Properties of the Payment schedule Property Class into one Product and asks you to configure the system to allow this. What would be a correct response? |
| 1. This is not supported, can only have one Property for Payment schedule and this is not user configurable | 2. Define multiple properties in AA.PROPERTY table for Payment schedule property class | 3. Add the value MULTIPLE to the TYPE field in the Property Class | 4. Add multiple Properties to the Product Condition record | 5. Directly add multiple Properties to the Product group and define the conditions for those in AA.PRODUCT.DESIGNER |
| Answer: This is not supported, can only have one Property for Payment schedule and this is not user configurable |
| Question: A bank wishes to create an offer for a customer to extend the term of the existing loan with a new payment schedule, and show the customer the new payment schedule. Since this is only an offer which the customer may or may not accept, the bank user does not want to modify the live conditions. How is this done? |
| 1. Not possible using the existing arrangement, the user must create a new Arrangement | 2. The user creates a Simulation Capture which then calculates and displays the payment schedule | 3. The user creates a Simulation Capture for the requirement, runs the simulation, then looks at the simulated Arrangement Overview | 4. The user creates a Change Payment Schedule Activity, and puts it on HOLD and views the result of his input in overview screen | 5. |
| Answer: The user creates a Simulation Capture for the requirement, runs the simulation, then looks at the simulated Arrangement Overview |
| Question: What happens when an activity, which has a property condition which is processing a M function as part of it, is authorized? |
| 1. The activity would not be allowed to Authorize since there is no Authorization for M function | 2. The activity would be authorized and system would perform an Authorize process for M function as well. | 3. The activity would be allowed to Authorize, but the property with the M function would be skipped during this. | 4. The activity with M function as part of it, should only be processed as Zero authorization since M processes both input and Authorize in one go only. | 5. |
| Answer: The activity would be authorized and system would perform an Authorize process for M function as well. |
| Question: A bank wants to suspend the interest amount that is already overdue (in Bills) when the Arrangement begins to "suspend"(stops accruing to PL) . What should be done to achieve this? |
| 1. In AA.PROPERTY, PROPERTY.TYPE Field should be set as SUSPEND.OVERDUES for the interest record | 2. SUSPEND.OVERDUE Field should be set to "YES" in OVERDUE product condition | 3. For the interest property SUSPEND.OVERDUES should be set to YES | 4. SUSPEND field in OVERDUE product condition should be flagged as SUSPEND.OVERDUES | 5. |
| Answer: In AA.PROPERTY, PROPERTY.TYPE Field should be set as SUSPEND.OVERDUES for the interest record |
| Question: What is the purpose of defining Negotiation rules at the product condition level? |
| 1. So that all attribute values get defaulted in the Arrangement | 2. So that attribute values at the arrangement level may be modified according to the rules stated | 3. So that specific screen versions may be controlled at the arrangement level | 4. Decides the eligibility of a customer for a product | 5. Filters the eligible products for a customer in the catalog |
| Answer: So that attribute values at the arrangement level may be modified according to the rules stated |
| Question: A Bank desires that for Charges and Interest, they would like to create additional product conditions(to be designed at the Product level), to be applicable at a later date, at the Arrangement level. Is this possible to be set? |
| 1. Future dated product conditions cannot be created | 2. More than one product condition per Property cannot be created | 3. Yes, since the TYPE Field of the Property Class has been defined as CURRENCY | 4. Yes, since the TYPE Field of the Property Class has been defined as DATED | 5. Yes, since the TYPE Field of the Property Class has been defined as MULTIPLE |
| Answer: Yes, since the TYPE Field of the Property Class has been defined as DATED |
| Question: By referring to which application can we determine whether a given Property Class is mandatory for a line of business? |
| 1. AA.PROPERTY | 2. AA.PROPERTY.CLASS | 3. AA.PRODUCT.LINE | 4. AA.PRODUCT | 5. AA.ARRANGEMENT |
| Answer: AA.PRODUCT.LINE |
| Question: While setting rules for Term and Amount for Corporate loans, a Bank has decided to set DEFAULT.NEGOTIABLE Field as Yes and not to set any Negotiation rules. What will be the effect of this setting? |
| 1. All Fields that have a default value would be defaulted at Arrangement level and the Term and Amount related choices are fully negotiable | 2. All Fields that have a default value would be defaulted at Arrangement level and the Term and Amount related choices are fully Non negotiable | 3. It is not possible to set like this. The Bank should indicate Fields that are Not Negotiable | 4. It is not possible to set like this. The Bank should indicate Fields that are Negotiable | 5. |
| Answer: All Fields that have a default value would be defaulted at Arrangement level and the Term and Amount related choices are fully negotiable |
| Question: Which of the following statements is not true with respect to Inheritance in AA? |
| 1. Parent products can also be sold | 2. Variations in products easily achieved | 3. A product can have unlimited number of children | 4. Any number of parents can be specified for a product | 5. |
| Answer: Any number of parents can be specified for a product |
| Question: A Bank desires that during renewal activities product conditions should have the option of being maintained at the arrangement level or can be reset from the product. Is this possible? |
| 1. This is not possible as property conditions are automatically reset during renewal activities. | 2. Field DEFAULT.ATTR.OPTION for respective product conditions should be set as 'RESETTING' or 'NON-RESETTING' | 3. Field DEFAULT.ATTR.OPTION for respective product condition should be set as 'TRACKING' or 'NON-TRACKING' | 4. Field DEFAULT.NEGOTIABLE for respective product conditions should be set as 'RESETTING' or 'NON-RESETTING' | 5. This is not possible as property conditions are automatically maintained at the arrangement level during renewal activities. |
| Answer: Field DEFAULT.ATTR.OPTION for respective product conditions should be set as 'RESETTING' or 'NON-RESETTING' |
| Question: A bank wishes to offer a lending product for which the minimum loan amount is 100,000. However, there is no limit for maximum loan amount. Is it possible to configure this in Term Amount Product condition ? |
| 1. The AMOUNT field should be defined with no default value and set to Negotiable upto a MAXIMUM of 100,000 | 2. The AMOUNT field need not have any default value. However, the AMOUNT field should be set as negotiable subject to a MINIMUM amount of 100,000 and less than which it should generate an error message. | 3. The AMOUNT field should be defined with a default value of 100,000 and set as Non-Negotiable | 4. The AMOUNT field must be defined with a default value and set to Negotiable upto a MAXIMUM of 100,000 beyond which it should generate error message. | 5. The AMOUNT field should be defined with no default value and set as Non-Negotiable |
| Answer: The AMOUNT field need not have any default value. However, the AMOUNT field should be set as negotiable subject to a MINIMUM amount of 100,000 and less than which it should generate an error message. |
| Question: A bank wishes to offer loans with a Fixed Term of 2 Years. However, in special cases, it would allow the term to be extended upto 4 Years, but the minimum term should not be less than 2 years. How can this be achieved in Term amount product condition? |
| 1. The TERM field should be defined with no default value and set as Negotiable with a MINPERIOD of 4Y, below which it should generate an Error message | 2. This cannot be set in AA | 3. The TERM field should be defined with an optional default value of 4Y or above and set as Negotiable with a MINPERIOD of 3Y, below which it should generate an Override message | 4. The TERM field should be defined with a default value of 2Y. Also, the TERM field should be set as Negotiable with a MINPERIOD of 2Y and MAXPERIOD of 4Y with error messages when the value is less is less than 2Y or more than 4Y | 5. The TERM field should be defined with an optional default value of 3Y or above and set as Negotiable with a MINPERIOD of 4Y, below which it should generate an Override message |
| Answer: The TERM field should be defined with a default value of 2Y. Also, the TERM field should be set as Negotiable with a MINPERIOD of 2Y and MAXPERIOD of 4Y with error messages when the value is less is less than 2Y or more than 4Y |
| Question: A bank wishes to offer "Special Deposits" which generally have a Term of 5 Years or more. In special cases, the bank wishes to approve an arrangement which is less than 5 years. How can this be specified in Term amount product condition? |
| 1. This cannot be set in AA | 2. The TERM field should be defined with no default value and set as Negotiable with a MINPERIOD of 5Y, below which it should generate an Error message | 3. The TERM field should be defined with no default value and set as Negotiable with a MINIMUM of 5Y, below which it should generate an Error message | 4. The TERM field should be defined with an optional default value of 5Y or above and set as Negotiable with a MINIMUM of 5Y, below which it should generate an Override message | 5. The TERM field should be defined with an optional default value of 5Y or above and set as Negotiable with a MINPERIOD of 5Y, below which it should generate an Override message |
| Answer: The TERM field should be defined with an optional default value of 5Y or above and set as Negotiable with a MINPERIOD of 5Y, below which it should generate an Override message |
| Question: A consultant wants to define AC.BALANCE.TYPE for all ageing types when he is designing a loan product. Where could he find the prefixes for the Ageing balance types? |
| 1. AA.PROPERTY.CLASS | 2. AA.PROPERTY | 3. AA.PRODUCT.DESIGNER | 4. EB.LOOKUP definition of AA.OVERDUE.STATUS | 5. |
| Answer: EB.LOOKUP definition of AA.OVERDUE.STATUS |
| Question: When Changing Products, what must the two products have in common? |
| 1. They must have the same Account Product Condition | 2. Nothing. If CHG.TO.PRODUCT is left blank, allowed to switch to all products | 3. They must have the same Interest Product Condition | 4. They must be members of the same Product Group | 5. |
| Answer: They must be members of the same Product Group |
| Question: A bank wishes to offer a Special Deposit for which the minimum amount should be set as 100,000. However, there is no limit on the maximum deposit amount. Is it possible to configure this in Term Amount Product condition ? |
| 1. The AMOUNT field need not have any default value. However, the AMOUNT field should be set as negotiable subject to a MINIMUM amount of 100,000 and less than which it should generate an error message. | 2. The AMOUNT field should be defined with a default value of 100,000 and set as Non-Negotiable | 3. The AMOUNT field should be defined with no default value and set to Negotiable upto a MAXIMUM of 100,000 | 4. The AMOUNT field must be defined with a default value and set to Negotiable upto a MAXIMUM of 100,000 beyond which it should generate error message. | 5. The AMOUNT field should be defined with no default value and set as Non-Negotiable |
| Answer: The AMOUNT field need not have any default value. However, the AMOUNT field should be set as negotiable subject to a MINIMUM amount of 100,000 and less than which it should generate an error message. |
| Question: A bank wishes to offer deposits with a "Fixed Term of 3Y". However, in special cases, it would allow the term to be extended upto 4Y, but it will not accept deposit less than 3Y. How can this be achieved in Term amount product condition? |
| 1. The TERM field should be defined with default value of 3Y. Also, the TERM field should be set as Negotiable with a MINPERIOD of 3Y and MAXPERIOD of 4Y with error messages when the value is less is than 3 years and greater than 4 years. | 2. The TERM field should be defined with an optional default value of 4Y or above and set as Negotiable with a MINPERIOD of 3Y, below which it should generate an Override message | 3. This cannot be set in AA | 4. The TERM field should be defined with no default value and set as Negotiable with a MINPERIOD of 4Y, below which it should generate an Error message | 5. The TERM field should be defined with an optional default value of 3Y or above and set as Negotiable with a MINPERIOD of 4Y, below which it should generate an Override message |
| Answer: The TERM field should be defined with default value of 3Y. Also, the TERM field should be set as Negotiable with a MINPERIOD of 3Y and MAXPERIOD of 4Y with error messages when the value is less is than 3 years and greater than 4 years. |
| Question: "The following is a Product Condition for the Term Amount Property Class: Attribute.1: TERM Options.1: NEGOTIABLE Type.1: MINPERIOD Value.1: 1Y Message.1: OVERRIDE Attribute.2 : REVOLVING Options.2 : OVERRIDE Default Negotiable : NO Which of the following is a correct statement?" |
| 1. While inputting an Arrangement, an Override will be displayed if the TERM entered is greater than 1Y and an Override will be displayed if the REVOLVING field is negotiated | 2. This is an incorrect definition. For the Attribute REVOLVING, OVERRIDE is an invalid option when Default Negotiable is NO | 3. While inputting an Arrangement, an Error will be displayed if the TERM entered is less than 1Y and an Override will be displayed if the REVOLVING field is left blank | 4. While inputting an Arrangement, an Error will be displayed if the TERM entered is greater than 1Y and an Override will be displayed if the REVOLVING field is left blank | 5. |
| Answer: This is an incorrect definition. For the Attribute REVOLVING, OVERRIDE is an invalid option when Default Negotiable is NO |
| Question: The bank wants to see only the Inputtable properties on the screen and does not wish to see any other properties - for example during UPDATE-OFFICERS property, it only wants to see OFFICERS property and does not wish to see Interest, Payment schedule etc. Can this be done? |
| 1. Yes - Do not define any versions for the properties that you don’t wish to see | 2. No - this cannot be controlled as it is managed by core | 3. Yes - through configuration in ACTIVITY.PRESENTATION property | 4. Yes - this can be controlled through VERSION application | 5. |
| Answer: Yes - through configuration in ACTIVITY.PRESENTATION property |
| Question: When a CHANGE-INTEREST activity is opened in AA.SIMULATION.CAPTURE, which application is opened in Input mode ? |
| 1. AA.ARR.INTEREST | 2. AA.SIM.INTEREST | 3. AA.ARR.INTEREST$SIM | 4. AA.PRD.CAT.INTEREST | 5. |
| Answer: AA.SIM.INTEREST |
| Question: A bank wants to define a property(and its conditions) - say Officers property - at the product level and does not want the property to appear when taking arrangements/doing amendments. How can this be achieved? |
| 1. Skip defining that property in AA.PRODUCT.GROUP | 2. Define the property as PRODUCT.ONLY in AA.PROPERTY and include it like any other property in the product | 3. Skip defining that property in AA.PRODUCT.DESIGNER | 4. Do not include the property in ACTIVITY.PRESENTATION so that it does not appear on the screen | 5. |
| Answer: Define the property as PRODUCT.ONLY in AA.PROPERTY and include it like any other property in the product |
| Question: When an Interest property is defined as SUSPEND and SUSPEND.OVERDUES in PROPERTY.TYPE field what does it indicate? |
| 1. When the arrangement is taken out, the interest gets suspended | 2. When a contract goes overdue, the system gets suspended | 3. When a contract becomes overdue and reaches a status set for suspension, this property suspends all of its past and current dues | 4. When a contract becomes overdue and reaches a status set for suspension, the property starts suspending subsequent dues | 5. It is not possible to define both |
| Answer: When a contract becomes overdue and reaches a status set for suspension, this property suspends all of its past and current dues |
| Question: When an Interest property is defined as SUSPEND in PROPERTY.TYPE field, what does it indicate? |
| 1. When the arrangement is taken out, the interest gets suspended | 2. When a contract goes overdue, the system gets suspended | 3. When a contract becomes overdue and reaches a status set for suspension, this property suspends all of its past and current dues | 4. When a contract becomes overdue and reaches a status set for suspension, the property starts suspending subsequent dues | 5. It is not possible to define SUSPEND without defining SUSPEND.OVERDUES |
| Answer: When a contract becomes overdue and reaches a status set for suspension, the property starts suspending subsequent dues |
| Question: When a Interest property is defined as "RESIDUAL.ACCRUAL" in PROPERTY.TYPE field of AA.PROPERTY, what feature does it provide? |
| 1. Interest would accrue only on residual amount stated in the Payment schedule | 2. When interest accrued is greater than the amount made due for interest for that period, the excess amount may be moved to RES balance of this property | 3. When interest accrued is greater than the amount made due for interest for that period, the excess amount may be moved to RES balance of this property | 4. When interest accrued is greater than the amount made due for interest for that period, the excess amount would be updated in RESIDUAL.AMOUNT field of Payment schedule record | 5. |
| Answer: When interest accrued is greater than the amount made due for interest for that period, the excess amount may be moved to RES balance of this property |
| Question: A Bank has designed a product which has a promotional interest rate for the first year and from second year onwards, it moves to standard rates. The bank wants users to be allowed to negotiate this standard rate when the new arrangement is taken. What can the bank do to allow negotiation on this condition during NEW arrangement itself? |
| 1. This is not possible. The bank has to perform a CHANGE-INTEREST activity separately for that condition | 2. No special setting is required. When a future product condition is defined, it automatically appears in NEW arrangement itself as multiple interest tabs | 3. The property needs to be set as FORWARD.DATED in type field of AA.PROPERTY file so that they appear alongside the current condition as multiple tabs | 4. System does not allow forward conditions to be negotiated as the condition exists only at product level | 5. |
| Answer: The property needs to be set as FORWARD.DATED in type field of AA.PROPERTY file so that they appear alongside the current condition as multiple tabs |
| Question: When a user opens a NEW arrangement activity, he sees one of the properties where certain values are defaulted, but all fields remain NOINPUT. What could be the possible reason for this? Assume there are no attribute(field) level rules defined in the product condition |
| 1. The condition has DEFAULT.NEGOTIABLE attribute set to NO at the product condition | 2. The condition has NON.TRACKING set in the ARR.LINK field | 3. The condition has CUSTOM.TRACKING set in the ARR.LINK field | 4. The property is defined as PRODUCT.ONLY. Hence no negotiation is allowed at the arrangement | 5. |
| Answer: The condition has DEFAULT.NEGOTIABLE attribute set to NO at the product condition |
| Question: An arrangement has the following activities performed on it: 05-Jan : User activity - U1 (User) 07-Jan : Transaction activity - T1 10-Jan : Scheduled activity - S1(SOD) Today : 15-Jan A Backdated User activity U2 was performed effective 05-Jan. What is the order of process of the Activities involved. |
| 1. 10-Jan : S1 - Reverse 07-Jan : T1 - Reverse 07-Jan : U1 - Reverse 07-Jan: U1 - Input 05-Jan : U2 - Input 07-Jan : T1 - Input 10-Jan : S1 - Input | 2. 10-Jan : S1 - Reverse 07-Jan : T1 - Reverse 07-Jan : U1 - Reverse 05-Jan : U2 - Input 07-Jan : T1 - Input 10-Jan : S1 - Input | 3. 10-Jan : S1 - Reverse 07-Jan : T1 - Reverse 05-Jan : U2 - Input 07-Jan : T1 - Input 10-Jan : S1 - Input | 4. 10-Jan : T1 - Reverse 07-Jan : S1 - Reverse 05-Jan : U2 - Input 07-Jan : T1 - Input 10-Jan : S1 - Input | 5. |
| Answer: 10-Jan : S1 - Reverse 07-Jan : T1 - Reverse 05-Jan : U2 - Input 07-Jan : T1 - Input 10-Jan : S1 - Input |
| Question: An arrangement has the following activities performed on it: 07-Jan : Transaction activity - T1 10-Jan : Scheduled activity - S1(SOD) Today : 15-Jan A Backdated User activity U1 was performed effective 05-Jan and kept in INAU. What is the order of process of the Activities involved when this U1 is Authorised |
| 1. 10-Jan : S1 - Reverse Delete 07-Jan : T1 - Reverse Delete 05-Jan : U1 - Input Authorise 07-Jan : T1 - Input Authorise 10-Jan : S1 - Input Authorise | 2. 05-Jan : U1 - Input Authorise | 3. 10-Jan : S1 - Input Authorise 07-Jan : T1 - Input Authorise 05-Jan : U1 - Input Authorise 07-Jan : T1 - Reverse-Authorise 10-Jan : S1 - Reverse-Authorise | 4. 10-Jan : S1 - Reverse Authorise 07-Jan : T1 - Reverse Authorise 05-Jan : U1 - Input Authorise 07-Jan : T1(Replay) - Input Authorise 10-Jan : S1(Replay) - Input Authorise | 5. |
| Answer: 10-Jan : S1 - Reverse Authorise 07-Jan : T1 - Reverse Authorise 05-Jan : U1 - Input Authorise 07-Jan : T1(Replay) - Input Authorise 10-Jan : S1(Replay) - Input Authorise |
| Question: An arrangement has the following activities performed on it: 05-Jan : User activity - U1 (User) 07-Jan : Transaction activity - T1 10-Jan : Scheduled activity - S1(SOD) Today : 15-Jan The user Activity U1 is now reversed. What is the order of process of the Activities involved. |
| 1. 10-Jan : S1 - Reverse 07-Jan : T1 - Reverse 05-Jan : U1 - Input 07-Jan : T1 - Input 10-Jan : S1 - Input | 2. 10-Jan : S1 - Reverse 07-Jan : T1 - Reverse 05-Jan : U1 - Reverse 07-Jan : T1 - Input 10-Jan : S1 - Input | 3. 05-Jan : U1 - Reverse 07-Jan : T1 - Reverse 10-Jan : S1 - Reverse | 4. 10-Jan : T1 - Reverse 07-Jan : S1 - Reverse 05-Jan : U1 - Reverse 07-Jan : T1 - Input 10-Jan : S1 - Input | 5. |
| Answer: 10-Jan : S1 - Reverse 07-Jan : T1 - Reverse 05-Jan : U1 - Reverse 07-Jan : T1 - Input 10-Jan : S1 - Input |
| Question: An arrangement has the following activities performed on it: 05-Jan : User activity - U1 (User) 07-Jan : Transaction activity - T1 10-Jan : Scheduled activity - S1(SOD) Today : 15-Jan The user Activity U1 was reversed. What is the order of process of the Activities involved when U1 is now Authorized? |
| 1. 05-Jan : U1 - Reverse Auth 07-Jan : T1 - Reverse Auth 10-Jan : S1 - Reverse Auth | 2. 10-Jan : S1 - Reverse Auth 07-Jan : T1 - Reverse Auth 05-Jan : U1 - Reverse Auth 07-Jan : T1(replay) - Input Auth 10-Jan : S1(replay) - Input Auth | 3. 10-Jan : S1 - Reverse Delete 07-Jan : T1 - Reverse Delete 05-Jan : U1 - Reverse Auth 07-Jan : T1(replay) - Input Auth 10-Jan : S1(replay) - Input Auth | 4. 10-Jan : S1 - Reverse Auth 07-Jan : T1 - Reverse Auth 05-Jan : U1(replay) - Input Auth 07-Jan : T1(replay) - Input Auth 10-Jan : S1(replay) - Input Auth | 5. |
| Answer: 10-Jan : S1 - Reverse Auth 07-Jan : T1 - Reverse Auth 05-Jan : U1 - Reverse Auth 07-Jan : T1(replay) - Input Auth 10-Jan : S1(replay) - Input Auth |
| Question: An arrangement has the following activities performed on it: 05-Jan : User activity - U1 (User) 07-Jan : Transaction activity - T1 10-Jan : Scheduled activity - S1(SOD) Today : 15-Jan The user Activity U1 was reversed. What is the order of process of the Activities involved when U1 is now deleted? |
| 1. 10-Jan : S1(replayed) - Input Delete 07-Jan : T1(replayed) - Input Delete 05-Jan : U1 - Reverse Delete 07-Jan : T1 - Reverse Delete 10-Jan : S1 - Reverse Delete | 2. 10-Jan : S1 - Reverse Delete 07-Jan : T1 - Reverse Delete 05-Jan : U2 - Reverse Delete 07-Jan : T1(replayed) - Input Delete 10-Jan : S1(replayed) - Input Delete | 3. 05-Jan : U1 - Reverse delete 07-Jan : T1 - Reverse Delete 10-Jan : S1 - Reverse Delete | 4. 10-Jan : S1 - Reverse Auth 07-Jan : T1 - Reverse Auth 05-Jan : U1 - Reverse Auth 07-Jan : T1 - Input Auth 10-Jan : S1 - Input Auth | 5. |
| Answer: 10-Jan : S1(replayed) - Input Delete 07-Jan : T1(replayed) - Input Delete 05-Jan : U1 - Reverse Delete 07-Jan : T1 - Reverse Delete 10-Jan : S1 - Reverse Delete |
| Question: Which of the following best describes the CAN.PROP.CLASS/CAN.ACTION fields in AA.ACTIVITY.CLASS? |
| 1. These determine the order of action processing when an activity is reversed | 2. System would ignore the PROPERTY.CLASS/ACTION fields for reversal when CAN.PROP.CLASS/CAN.ACTION fields are defined | 3. When there is no entry in these fields, system would take the PROPERTY.CLASS/ACTION definition in reverse order when the activity is reversed | 4. All 3 of the above | 5. |
| Answer: All 3 of the above |
| Question: What does the field USER.INPUT in AA.ACTIVITY.CLASS determine? Assume the activity performed belongs to the AA.ACTIVITY.CLASS in question |
| 1. It determines whether user is allowed to input when triggering the activity | 2. It determines which version could be defined in ACTIVITY.PRESENTATION | 3. There should atleast be one USER.INPUT activity in any class- otherwise, there is no point in releasing this activity | 4. Only USER.INPUT set to YES have valid process behind it. When it is set as NO, it means, there is no process behind it and is only opened in SEE mode | 5. |
| Answer: It determines whether user is allowed to input when triggering the activity |
| Question: All product conditions have a field called DEFAULT.ATTR.OPTION. Which of the following is true about the functionality of this field? |
| 1. It determines whether the arrangement condition should be retained or overwritten with the new product condition when CHANGE.PRODUCT happens | 2. It determines whether the condition allows fields to be negotiated or not | 3. It determines whether the default from product should happen when arrangement condition is opened | 4. It determines whether new fields may be added to the current condition or not | 5. |
| Answer: It determines whether the arrangement condition should be retained or overwritten with the new product condition when CHANGE.PRODUCT happens |
| Question: Which activity uses the field DEFAULT.ATTR.OPTION on product condition ? |
| 1. NEW-ARRANGEMENT | 2. CHANGE.PRODUCT-ARRANGEMENT | 3. RENEGOTIATE-ARRANGEMENT | 4. CHANGE-INTEREST | 5. All activities |
| Answer: CHANGE.PRODUCT-ARRANGEMENT |
| Question: Field DEFAULT.ATTR.OPTION is set to RESETTING in product conditions of P1 and P2 products, no other individual field attributes have been defined. What would happen to this condition at Arrangement when CHANGE.PRODUCT activity is performed from P1 to P2? |
| 1. P2's product condition would prevail | 2. P2's product condition would overwrite the current arrangement condition but would retain the already negotiated fields at the arrangement | 3. P1's negotiated condition would be defaulted onto P2's arrangement condition | 4. Arrangement condition would remain as it is and there would be no impact of P2's condition on it. | 5. |
| Answer: P2's product condition would prevail |
| Question: Field DEFAULT.ATTR.OPTION is set to NON-RESETTING in product conditions of both P1 and P2 products, no other individual field attributes have been defined. What would happen to this condition at Arrangement when CHANGE.PRODUCT activity is performed from P1 to P2? |
| 1. P2's product condition would overwrite the current condition irrespective of whatever has been negotiated on arrangement condition | 2. P2's product condition would overwrite the current arrangement condition but would retain the already negotiated fields at the arrangement | 3. P1's condition would be overwritten back onto arrangement condition irrespective of whatever has been negotiated on arrangement condition | 4. Arrangement condition would remain as it is and there would be no impact of P2's product condition on it. | 5. |
| Answer: Arrangement condition would remain as it is and there would be no impact of P2's product condition on it. |
| Question: Which of the following is true about DEFAULT.ATTR.OPTION attribute when set on a product condition? Assume arrangement is running on P1 and CHANGE.PRODUCT happens to P2. |
| 1. Only the DEFAULT.ATTR.OPTION definition on P1's product condition is taken into account when CHANGE.PRODUCT is triggered | 2. Since the product is moving to P2, the DEFAULT.ATTR.OPTION values set in P2's product property condition is taken into consideration | 3. The DEFAULT.ATTR.OPTION definition on both P1's and P2's product conditions should be defined in Sync, since the value set in both the conditions are taken into effect during CHANGE.PRODUCT activity | 4. The field has no relevance during CHANGE.PRODUCT activity | 5. |
| Answer: Only the DEFAULT.ATTR.OPTION definition on P1's product condition is taken into account when CHANGE.PRODUCT is triggered |
| Question: What does the field CHANGED.FIELDS in each of the Arrangement condition signify? |
| 1. It indicates the attributes that have been changed between the current instance and the immediately preceding previous instance of the Arrangement condition | 2. It indicates the fields that have been changed on the arrangement from the time it was taken | 3. It indicates the fields that have been modified by the system and not the by the user | 4. It indicates the changes of the current instance with that of the product condition at the same instance | 5. |
| Answer: It indicates the attributes that have been changed between the current instance and the immediately preceding previous instance of the Arrangement condition |
| Question: What does the field NEGOTIATED.FIELDS in each of the Arrangement condition signify? |
| 1. It indicates the attributes that have been changed between the current instance and the immediately preceding previous instance of the Arrangement condition | 2. It indicates the fields that have been changed on the arrangement from the time it was taken | 3. It indicates the fields that have been modified by the system and not the by the user | 4. It indicates the changes of the current instance with that of the product condition at the same instance | 5. |
| Answer: It indicates the fields that have been changed on the arrangement from the time it was taken |
| Question: A Lending arrangement is accruing daily on both Principal Interest and Penalty interest. A backdated activity is performed on this arrangement. Which of the following is true when this event happens? |
| 1. Only Principal interest gets adjusted and reaccrued | 2. Only penalty interest gets adjusted and reaccrued | 3. Both Principal interest and penalty interest gets adjusted and reaccrued | 4. No adjustment and reaccrual happens | 5. |
| Answer: Both Principal interest and penalty interest gets adjusted and reaccrued |
| Question: A Bank has designed a product with INHERITANCE.ONLY Field marked as Yes. Which of the following statements is false in this context? |
| 1. This product is not available for Sale | 2. This product passes on conditions to associated child products | 3. This product does not appear in the catalog | 4. This product can also be sold | 5. |
| Answer: This product can also be sold |
| Question: A Bank has defined an Interest Property as CREDIT in PROPERTY.TYPE Field. What is the significance of this setting? |
| 1. This cannot be set, Credit type allowed only for Charge Property | 2. This Interest property will be a payable Interest | 3. This Interest property will be a receivable interest | 4. When an arrangement is taken out, the interest gets credited | 5. |
| Answer: This cannot be set, Credit type allowed only for Charge Property |
| Question: The bank desires that when performing update activities, only the property that is to be amended / updated appear on the arrangement screen. Other properties should be hidden. For example, during an UPDATE-INTEREST activity, only INTEREST property should appear on the screen. Can this be done? |
| 1. Possible by not defining any versions for the properties that are not to be shown | 2. This cannot be controlled as it is managed by core | 3. Possible through configuration in ACTIVITY.PRESENTATION property | 4. Possible by controlling through VERSION application | 5. |
| Answer: Possible through configuration in ACTIVITY.PRESENTATION property |
| Question: When the activity CHANGE-PAYMENT.SCHEDULE is opened in AA.SIMULATION.CAPTURE, which application is opened in Input mode? |
| 1. AA.ARR.PAYMENT.SCHEDULE | 2. AA.SIM.PAYMENT.SCHEDULE | 3. AA.ARR.PAYMENT.SCHEDULE$SIM | 4. AA.PRD.CAT.PAYMENT.SCHEDULE | 5. |
| Answer: AA.SIM.PAYMENT.SCHEDULE |
| Question: A bank desires to define CHANGE.PRODUCT property and its conditions at the product level and does not want the property to appear when taking arrangements/doing amendments. How can this be achieved? |
| 1. Skip defining CHANGE.PRODUCT property in AA.PRODUCT.GROUP | 2. Define CHANGE.PRODUCT property as PRODUCT.ONLY in AA.PROPERTY and include it like any other property in the product | 3. This cannot be set as 'Product only' as it is managed by core | 4. Do not include the property in ACTIVITY.PRESENTATION so that it does not appear on the screen | 5. |
| Answer: Define CHANGE.PRODUCT property as PRODUCT.ONLY in AA.PROPERTY and include it like any other property in the product |
| Question: A Charge property is defined as SUSPEND and SUSPEND.OVERDUES in PROPERTY.TYPE field. What does this denote? |
| 1. When an arrangement is taken out, the charge gets suspended | 2. When a contract becomes overdue, the system gets suspended | 3. When a contract becomes overdue and reaches a status set for suspension, the charge property suspends all of its past and current dues | 4. When a contract becomes overdue and reaches a status set for suspension, the charge property starts suspending subsequent dues | 5. It is not possible to define both for charge property |
| Answer: When a contract becomes overdue and reaches a status set for suspension, the charge property suspends all of its past and current dues |
| Question: When a Charge property is defined as SUSPEND in PROPERTY.TYPE field, what does it denote? |
| 1. When an arrangement is taken out, the charge gets suspended | 2. When a contract becomes overdue, the system gets suspended | 3. When a contract becomes overdue and reaches a status set for suspension, the charge property suspends all of its past and current dues | 4. When a contract becomes overdue and reaches a status set for suspension, the charge property suspends subsequent dues | 5. It is not possible to define SUSPEND without defining SUSPEND.OVERDUES |
| Answer: When a contract becomes overdue and reaches a status set for suspension, the charge property suspends subsequent dues |
| Question: A Bank defines Charge property as "RESIDUAL.ACCRUAL" in PROPERTY.TYPE field of AA.PROPERTY, what feature does it provide? |
| 1. Charge would accrue only on residual amount stated in the Payment schedule | 2. When Charge accrued is greater than the charge amount made due for that period, the excess amount may be moved to RES balance of this property | 3. This is not possible to be set | 4. When Charge accrued is greater than the charge amount made due for that period, the excess amount would be updated in RESIDUAL.AMOUNT field of Payment schedule record | 5. |
| Answer: This is not possible to be set |
| Question: A Bank has defined a Charge Property as CREDIT in PROPERTY.TYPE Field. What is the significance of this setting? |
| 1. This cannot be set, Credit type allowed only for Interest Property | 2. This charge property will be a payable charge | 3. This charge property will be a receivable charge | 4. When an arrangement is taken out, this charge gets capitalized to the account | 5. |
| Answer: This charge property will be a payable charge |
| Question: When an arrangement is created for a product belonging to BUNDLE, currency field is not prompted. What could be the reason behind this? |
| 1. BUNDLE product line does not deal with currencies and the field LINE.ATTRIBUTE in AA.PRODUCT.LINE is set to null | 2. This is not possible because Bundle arrangement deals with Interest compensation and Interest Offset | 3. This is because none of the property classes belonging to Bundle product line has currency and amount fields | 4. Bundle arrangements have automatic default of currency from the underlying arrangements in the bundle | 5. |
| Answer: BUNDLE product line does not deal with currencies and the field LINE.ATTRIBUTE in AA.PRODUCT.LINE is set to null |
| Question: TRANSACTION.COUNT.TOTAL Periodic Attribute class could be used on which Property Class? |
| 1. Interest | 2. Term Amount | 3. Activity Restriction | 4. Account | 5. Charge |
| Answer: Activity Restriction |
| Question: An arrangement has an initial rate of 10% and interest rate is changed to 13%. A periodic rule is attached to the interest condition based on AA.PERIODIC.ATTRIBUTE.CLASS of RATE.INCREASE.TOLERANCE and rule value is stated as 20. The comparison type defined for this record is +TOLERANCE. Would the rule be broken during the rate change event assuming the rule period is met? |
| 1. Yes. Because you are only allowed a percentage increase of 2 since the rule value stated is a Basis points value | 2. No. Because you are allowed a percentage increase of up to 20 since the rule value stated is a Percentage value | 3. No. Because you are allowed a percentage increase of up to 3 percentage | 4. Yes. Because you are only allowed a maximum percentage of 10 percentage | 5. |
| Answer: Yes. Because you are only allowed a percentage increase of 2 since the rule value stated is a Basis points value |
| Question: FULL.DISBURSEMENT Periodic Attribute Class is to be used for which Property Class? |
| 1. Interest | 2. Term Amount | 3. Activity Restriction | 4. Account | 5. Charge |
| Answer: Term Amount |
| Question: A bank wants to setup a payable charge that will be capitalized on the payment date. How can this be configured? |
| 1. Define the charge property in PaymentSchedule with PAYMENT.METHOD set to CREDIT | 2. Payable charge cannot be set to capitalise | 3. Bank cannot pay a charge, only a customer can pay a charge | 4. Set TYPE in AA.PROPERTY to CREDIT for the Charge property and define the charge property in PaymentSchedule with PAYMENT.METHOD set to CAPITALISE | 5. Set TYPE in AA.PROPERTY to CREDIT for the Charge property and define the charge property in PaymentSchedule with PAYMENT.METHOD set to DUE |
| Answer: Set TYPE in AA.PROPERTY to CREDIT for the Charge property and define the charge property in PaymentSchedule with PAYMENT.METHOD set to CAPITALISE |
| Question: A charge property in AA.PROPERTY TYPE is set as CREDIT. What does this signify? |
| 1. Charge will would be assumed as payable charge | 2. Charge will always be capitalised | 3. Charge will always be assumed as payable charge, and will be capitalised | 4. Indicates that the charge would always to be credited to the bank. | 5. Does not signify anything unless it is defined in PaymentSchedule with PAYMENT.METHOD set to CAPITALISE, and BILL.TYPE set as PAY, where it would be considered as payable charge and will be capitalised |
| Answer: Charge will would be assumed as payable charge |
| Question: An arrangement is in suspended status, a charge collected as part of repayment is made due and is aged. Which of the following statements is True? |
| 1. Activity Charge due amount will not be suspended | 2. Activity Charge due amount will be suspended regardless of whether SUSPEND flag is set in AA.PROPERTY or not | 3. Activity Charge due amount will be suspended only when SUSPEND flag is set in AA.PROPERTY | 4. Activity Charges will not be aged hence charge amount will not be suspended | 5. Activity Charge due amount will be suspended only when SUSPEND and SUSPEND.ONLY flags are set in AA.PROPERTY |
| Answer: Activity Charge due amount will be suspended only when SUSPEND flag is set in AA.PROPERTY |
| Question: A Bank has set the field SUPPRESS.SEE.MODE as Yes in AA.PRD.DES.ACTIVITY.PRESENTATION. However, the fields in property Payment Schedule is also opened up while doing the change term in an arrangement. Why is it so ? |
| 1. It is due to the incorrect set up of product in AA.PRODUCT.DESIGNER. | 2. It is due to the incorrect set up in AA.PRD.DES.ACTIVITY.PRESENTATION. | 3. It is due to the incorrect set up in AA.PRODUCT.GROUP. | 4. When core AA.ACTIVITY.CLASS has defined a property class to be user inputtable, that cannot be suppressed using this flag | 5. It is due to the set up in AA.PROPERTY.CLASS |
| Answer: When core AA.ACTIVITY.CLASS has defined a property class to be user inputtable, that cannot be suppressed using this flag |
| Question: A Bank wants to input narrative while doing an Arrangement Activity and then display this narrative in Account Statement. Is it possible to achieve this in T24 ? |
| 1. No, it is neither possible to input narrative and nor to display the narrative in Account Statement. | 2. Though it is possible to input the narrative in Arrangement Activity, it is not possible to display the narrative in Account Statement. | 3. Yes, it is possible to both input and display narrative in Account Statement. | 4. Though it is possible to display the narrative field in Account Statement through Product Designer, it is not possible to input the narrative in Arrangement Activity. | 5. |
| Answer: Yes, it is possible to both input and display narrative in Account Statement. |
| Question: Which file can be amended by user? (assuming user has the relevant user access rights) |
| 1. AA.ARR.ACCOUNT.ACTIVITY | 2. AA.PRD.DES.ACCOUNT | 3. AA.PRD.CAT.ACCOUNT | 4. AA.PRD.PRF.ACCOUNT | 5. |
| Answer: AA.PRD.DES.ACCOUNT |
| Question: A user created a product, proofed and published it. Now when the user tried to take an arrangement, he could not find the product listed in the model screens when he drilled down from AA.PRODUCT.GROUP.What could be the reason? (Note: proof and publish completed without any error) |
| 1. Product was defined without mandatory properties | 2. Product was not proofed and published properly | 3. Product has INHERITANCE.ONLY set to YES | 4. Product available date is not proper in AA.PRODUCT.MANAGER | 5. |
| Answer: Product has INHERITANCE.ONLY set to YES |
| Question: What will happen when a product is proofed without populating the AVAILABLE.DATE field in AA.PRODUCT.MANAGER? |
| 1. Product is proofed and error is thrown at Product error field | 2. System assumes TODAY as the date of product availability | 3. No error is thrown | 4. Error thrown at Available date field since it is mandatory to fill this | 5. |
| Answer: Error thrown at Available date field since it is mandatory to fill this |
| Question: Is it possible to create product conditions for the CHARGE property class in the following format "Charge.cond---20091202"? |
| 1. It is not possible since currency is a mandatory component for all the product conditions of all the property classes | 2. It is not possible since product conditions created for the CHARGE property class need to have currency as part of their ID. | 3. It is possbile since currency is an optional component for the CHARGE product condition. | 4. It is possible because both currency and date are optional for the CHARGE product condition. | 5. |
| Answer: It is possbile since currency is an optional component for the CHARGE product condition. |
| Question: The user specifies the currency as GBP. When validating the activity the user gets the following error "NOT A VALID CURRENCY FOR THIS PRODUCT ". What is the reason for this? |
| 1. GBP is not defined in the CURRENCY file of T24. | 2. GBP is not defined as a currency in AA.PRODUCT.DESIGNER for the Product | 3. GBP is not defined a valid currency in AA.PRODUCT for the Product. | 4. Arrangements can only be entered in local currency. | 5. |
| Answer: GBP is not defined as a currency in AA.PRODUCT.DESIGNER for the Product |
| Question: Which of the following is not user definable in AA? |
| 1. AA.PRODUCT.LINE | 2. AA.PROPERTY | 3. AA.PRD.DES.XXXX(xxxx being the name of the property class) | 4. AA.ACTIVITY | 5. |
| Answer: AA.PRODUCT.LINE |
| Question: Which of the following is a valid activity ID format? |
| 1. ProductLine-Process-Property | 2. ProductGroup-Process-Property | 3. ProductLine-Property-Process | 4. ProductGroup-Property-Process | 5. |
| Answer: ProductLine-Process-Property |
| Question: Which is the application that determines whether reverse and replay is permitted for the product ? |
| 1. AA.PRODUCT.LINE | 2. AA.PROPERTY.CLASS | 3. AA.ACTIVITY.CLASS | 4. AA.PRODUCT | 5. |
| Answer: AA.PRODUCT.LINE |
| Question: User wishes to be able to define the screens of certain properties appearing on the arrangement screen. In which application within AA can this requirement be achieved? |
| 1. AA.PRD.DES.ACTIVITY.PRESENTATION | 2. AA.VERSION | 3. AA.PRODUCT.DESIGNER | 4. AA.PRD.DES.ACTIVITY.MESSAGING | 5. |
| Answer: AA.PRD.DES.ACTIVITY.PRESENTATION |
| Question: Which of the following application allows user to input transaction amount values required to simulate a payment in AA ? |
| 1. AA.ARRANGEMENT.ACTIVITY | 2. AA.SIM.PAYMENT.RULES | 3. AA.SIMULATION.RUNNER | 4. AA.SIMULATION.SERVICE | 5. |
| Answer: AA.SIMULATION.RUNNER |
| Question: The number of activities triggered for an arrangement was more than 300. The user is unable to view 'older' activities in the typical activity log on the Arrangement Overview screen. In which file can he locate these activities ? |
| 1. AA.SCHEDULED.ACTIVITY | 2. AA.ACTIVITY.HISTORY | 3. AA.ACTIVITY.HISTORY.HIST | 4. AA.ARRANGEMENT.ACTIVITY$HIS | 5. |
| Answer: AA.ACTIVITY.HISTORY.HIST |
| Question: The Bank created a new activity charge property and updated in the product group. They also included the corresponding product condition in the product. After successfully proofing and publishing the product, the user starts to perform the activity which is intended to trigger the fee. However, he received an error message "AA ACTIVITY MISSING" when trying to commit the transaction. What will be the reason? |
| 1. User forgot to create an activity manually for the new property | 2. The Bank missed out a step to select REBUILD.ACTIVITIES to Yes when attaching the new property in the product group | 3. The Bank missed out a step to re-proof and re-publish after the changes of the new property | 4. It is not possible. System will automatically create activity for all new properties | 5. |
| Answer: The Bank missed out a step to select REBUILD.ACTIVITIES to Yes when attaching the new property in the product group |
| Question: A user is not able to reverse a particular activity in the system. What might be the reason? |
| 1. AA.ACTIVITY.CLASS is defined as NOREVERSE | 2. AA.ACTIVITY.CLASS is defined as NOREPLAY | 3. AA.ACTIVITY is defined as NOREVERSE | 4. It is not possible, as all activity in the system are reversable | 5. |
| Answer: AA.ACTIVITY.CLASS is defined as NOREVERSE |
| Question: Which enquiry allows the user to monitor the simulation in AA? |
| 1. AA.SIMULATION.MONITOR | 2. AA.SIMULATION.VIEW | 3. AA.ARRANGEMENT.SIMULATION.VIEW | 4. AA.SIMULATION.RUNNER | 5. |
| Answer: AA.SIMULATION.MONITOR |
| Question: A bank user is not able to trigger an activity as secondary activity from parent activity. What might be the reason? |
| 1. TYPE is not defined to secondary in property class | 2. RELATED.ACTIVITY is not defined in AA.ACTIVITY | 3. AA.ACTIVITY is not linked to the parent activity | 4. ACTIVITY.TYPE is not set to secondary for the particular activity class | 5. |
| Answer: ACTIVITY.TYPE is not set to secondary for the particular activity class |
| Question: A product may not be available to users to take arrangements for various reasons. Which of the following is NOT one of them? |
| 1. Even though the product is set as Saleable, it has been set to look at a PARENT.PRODUCT in product designer. | 2. It is set to inheritance only in product designer | 3. Product is not proofed and published properly | 4. It is marked as "EXTERNAL" product in AA.PRODUCT.GROUP | 5. |
| Answer: Even though the product is set as Saleable, it has been set to look at a PARENT.PRODUCT in product designer. |
| Question: How can we define the product condition record for a particular variant? |
| 1. As part of ID of AA.PRD.DES.XXX record | 2. As part of ID of the AA.PRODUCT.DESIGNER | 3. As part of ID of the AA.PRODUCT.CATALOG | 4. None of the above | 5. |
| Answer: As part of ID of AA.PRD.DES.XXX record |
| Question: Which of the statement is FALSE? |
| 1. Only one activity can be simulated at one time | 2. AA Simulation can be run for future dated activities | 3. Simulation performs activities without creating or updating live records | 4. Simulated activities can be retained for user-defined days | 5. |
| Answer: Simulated activities can be retained for user-defined days |
| Question: Today is 20 May 2014. In the AA.PERIODIC.ATTRIBUTE defined by the Bank, PERIOD.TYPE field is ROLLING and PERIOD is 1Y. Restriction is on number of account withdrawals. What is the evaluation period of the restriction if a withdrawal is performed today ? |
| 1. Till maturity of the arrangement | 2. From 20 May 2013 to 20 May 2014 | 3. From 20 May 2014 to 20 May 2015 | 4. From initial 1 year from arrangement start date | 5. |
| Answer: From 20 May 2013 to 20 May 2014 |
| Question: There is only one FIXED.RATE interest condition used by the product. However, at the arrangement level, user wants to be able to define multiple fixed interest conditions for different time periods of a loan. e.g. 5% for first year and 6% for second year and so on. How can this be achieved ? |
| 1. In product designer, define the same condition ID twice (but with different effective dates) and mention the period (number of days) in the field EFFECTIVE | 2. At product level, make all the fields for interest product condition as negotiable and multi value the attributes at arrangement level to define the different interest conditions for different periods | 3. In the interest property record, define its type as 'forward dated'. Make all fields required for input negotiable. At the arrangement level, multi value the respective interest condition tabs for different periods | 4. We need to mention two separate interest product condition and need to make them negotiable at arrangement level and mention the period (number of days) in the EFFECTIVE field | 5. |
| Answer: In the interest property record, define its type as 'forward dated'. Make all fields required for input negotiable. At the arrangement level, multi value the respective interest condition tabs for different periods |
| Question: The Bank reported an issue to TEMENOS. They said that their users are not able to input a value in the End Date field within the payment schedule condition. However, they could input value in the Start Date field within the same condition. What could be the reason ? |
| 1. The End Date field in Payment Schedule condition was set to Custom Tracking | 2. The End Date field in Payment Schedule condition was set to Tracking | 3. The End Date field in Payment Schedule condition was set to Non-Negotiable | 4. The End Date field in Payment Schedule condition was set to Product Only | 5. 3 and 4 |
| Answer: The End Date field in Payment Schedule condition was set to Non-Negotiable |
| Question: If a property class is defined as TRACKING.ONLY, which of the following options best describe its characteristic? |
| 1. The property of this type would not appear(even in SEE mode) at the Arrangement level | 2. The actions belonging to this property do get executed | 3. The property of this type would appear at the Arrangement level(in SEE mode only) | 4. Both 1 and 2 | 5. Both 2 and 3 |
| Answer: Both 2 and 3 |
| Question: Bank wants to set up a type of fee where they can pay brokers for introducing new loan business. This fee is payable at the new loan opening stage. What should be the property type ? |
| 1. Credit | 2. Not possible | 3. Pay | 4. Bonus | 5. Broker |
| Answer: Credit |
| Question: The Bank informed that they do not have 'officers' in the loan department. Their loan users are called 'managers'. As such, the Bank wants a new property named 'Managers' for the Officers property class. The Bank created this new property and included in the product design. After re-proofing and re-publishing the product, the Bank created new loan arrangements. Subsequently, the user wanted to update the manager's ID for a particular loan. The user discovered that he cannot find 'Update Managers' within the list of 'New Activity'. What could have happened ? |
| 1. Balance Types for Managers have not been defined | 2. Product Group was not rebuilt | 3. The 'Managers' property should be included in the child product, not parent product | 4. The condition attached to 'Managers' property was set to Custom Tracking | 5. |
| Answer: Product Group was not rebuilt |
| Question: The Bank has 3 loan products. New arrangement fee is applicable for all the 3 products. For the first product, the fee is a flat USD 100. For the second product, the fee is a flat USD 200. For the third product, the fee is 1%. Upon proofing and publishing the parent product, the system throws an error for the third product. What could have happened ? |
| 1. All balance types for New Arrangement Fee have not been defined | 2. Calculation Source has not been defined for the new arrangement fee | 3. The fee for the third product should have been defined at parent product | 4. 1 and 2 | 5. |
| Answer: Calculation Source has not been defined for the new arrangement fee |
| Question: The Bank wants to be able to pay a bonus interest to customer if customer requests the loan to be disbursed within first 5 days of the loan creation. Is it possible to define such bonus interest in the system ? |
| 1. Yes, fully supported | 2. Not possible at all | 3. Yes, but the bonus interest has to be defined as a fee property in the system | 4. Yes, but we must also remember to define the overdue balance types for the bonus interest | 5. |
| Answer: Yes, but the bonus interest has to be defined as a fee property in the system |
| Question: What is the effect of setting ACCRUAL.BY.BILLS for the disbursement fee property ? |
| 1. No effect | 2. We can identify the fee accrued amount per bill | 3. We can identify the fee amortised amount per bill | 4. System will produce a bill for every accrual | 5. |
| Answer: No effect |
| Question: Bank has managed to proof and publish the new product successfully. Upon checking the product catalog, they could not locate this product at all. What could have happened ? |
| 1. Product is a parent product. They did not set 'Inheritance Only' to YES | 2. The field GROUP.TYPE for the Product Group has been set to 'External' | 3. The field GROUP.TYPE for the Product Group has been set to 'Internal' | 4. The field ATTRIBUTE for the Product Group has not been defined | 5. |
| Answer: The field GROUP.TYPE for the Product Group has been set to 'External' |
| Question: Bank wants to accrue new arrangement fee. What must they do to achieve this ? |
| 1. Define accrual period in ACCOUNTING condition | 2. Define AA.ACCRUAL.FREQUENCY | 3. Define accrual balance types for new arrangement fee | 4. All of the above | 5. Not possible |
| Answer: Not possible |
| Question: In the Officer condition used in Deposit products, the Bank wants to restrict the list of values in the PRIMARY.OFFICER attribute. The only list of values allowed for selection is 1, 2, 3 and 4. How should they define the negotiation rules for the PRIMARY.OFFICER attribute ? |
| 1. For the attribute PRIMARY.OFFICER, define MINIMUM as the NR.TYPE (Comparison Type) and 1 as the NR.VALUE. In addition, sub value to define MAXIMUM as the NR.TYPE (Comparison Type) and 4 as the NR.VALUE | 2. For the attribute PRIMARY.OFFICER, define EQUAL as the NR.TYPE (Comparison Type) and 1 2 3 4 as the NR.VALUE | 3. For the attribute PRIMARY.OFFICER, define MULTIPLE as the NR.TYPE (Comparison Type) and 1 as the NR.VALUE. In addition, sub value to define MAXIMUM as the NR.TYPE (Comparison Type) and 4 as the NR.VALUE | 4. For the attribute PRIMARY.OFFICER, define RANGE as the NR.TYPE (Comparison Type) and 1 2 3 4 as the NR.VALUE | 5. |
| Answer: For the attribute PRIMARY.OFFICER, define RANGE as the NR.TYPE (Comparison Type) and 1 2 3 4 as the NR.VALUE |
| Question: The Bank has defined PCHARGE as the periodic charge property for its lending products. What are the balance types that need to be created ? |
| 1. DUEPCHARGE | 2. ACCPCHARGE, DUEPCHARGE, GRCPCHARGE, DELPCHARGE, NABPCHARGE | 3. DUEPCHARGE, GRCPCHARGE, DELPCHARGE, NABPCHARGE | 4. No need to define balance types | 5. |
| Answer: DUEPCHARGE |
| Question: The Bank was informed of a very useful file known as AA.ACTIVITY.HISTORY. They checked through the file and were shocked that they are unable to locate any historical interest accrual activity listed for the loan. What is the reason ? |
| 1. There is a bug | 2. ACTIVITY.TYPE in AA.ACTIVITY.CLASS for LENDING-ACCRUE-INTEREST is defined as NOLOG | 3. ACTIVITY.TYPE in AA.ACTIVITY.CLASS for LENDING-ACCRUE-INTEREST is defined as NORR | 4. ACTIVITY.TYPE in AA.ACTIVITY.CLASS for LENDING-ACCRUE-INTEREST is defined as NOACCRUAL | 5. |
| Answer: ACTIVITY.TYPE in AA.ACTIVITY.CLASS for LENDING-ACCRUE-INTEREST is defined as NOLOG |
| Question: A loan is scheduled to mature on 20 May 2014. When does the maturity processing take place assuming the system moves from 18-May 2014 to 20-May-2014 ? |
| 1. On 20 May 2014 Start of Day | 2. On 20 May 2014 End of Day | 3. On 18 May 2014 Start of Day | 4. On 18 May 2014 End of Day | 5. |
| Answer: On 20 May 2014 Start of Day |
| Question: The Bank wants to define a new periodic attribute for the periodic attribute class TRANSACTION.AMOUNT.TOTAL. While they were defining, they came across a field COMPARISON.TYPE. What is the value that they need to indicate in this particular field ? |
| 1. Any comparison type which allows the data type 'AMT' | 2. Depends on the list of values found in COMPARISON.TYPE field within the corresponding AA.PROPERTY.CLASS record | 3. Any comparison type which allows the data type 'A' | 4. Depends on the list of values found in COMPARISON.TYPE field within this AA.PERIODIC.ATTRIBUTE.CLASS record | 5. |
| Answer: Depends on the list of values found in COMPARISON.TYPE field within this AA.PERIODIC.ATTRIBUTE.CLASS record |
| Question: The Bank wants to utilise the same set of versions for all their 3 deposit products. For the third deposit product, the Bank wants to ensure that system forces users to input a value in the END.DATE field within Payment Schedule condition. However, this is not required for the 2 other products. Is it possible to achieve this ? |
| 1. Not possible, different versions have to be used in order to achieve this | 2. Not possible because attributes in Payment Schedule condition are all negotiable | 3. Possible, define MANDATORY as the value in NR.OPTIONS for END.DATE attribute | 4. Possible, define FIX VALUE as the value in NR.OPTIONS for END.DATE attribute | 5. |
| Answer: Possible, define MANDATORY as the value in NR.OPTIONS for END.DATE attribute |
| Question: The Bank is thinking of launching a new loan product group known as 'Car Loans' and is in the midst of building these test products. In the Bank's test environment, they want to be able to differentiate these 'Test' loan products from the 'Live' loan products. As such, they are asking whether it is possible to place the test products in a separate folder on the product catalog, away from the live products. How can the Bank create such folder in the product catalog ? |
| 1. Not possible, local development is required | 2. Need to amend the ENQUIRY design of the product catalog | 3. Create a new product line named "Car Loans". System will automatically allocate this group of products in a separate folder based on the product line | 4. Create a new record for AA.PRODUCT.GROUP.ATTRIBUTE in EB.LOOKUP. Indicate this attribute when creating the product group | 5. |
| Answer: Create a new record for AA.PRODUCT.GROUP.ATTRIBUTE in EB.LOOKUP. Indicate this attribute when creating the product group |
| Question: Which of the following would be a typical use of 'Virtual Balance' in AA? |
| 1. If the Bank wants to calculate interest based on a summation of various balance types | 2. If the Bank wants to create a contingent loan, they can make use of Virtual Balance | 3. If the Bank wants to create a test product for testing purposes, the entries of this product should be "virtual" and not affect the live accounting entries | 4. If the Bank wants to simulate an arrangement, the balances need to be virtual, and not create real accounting entries | 5. |
| Answer: If the Bank wants to calculate interest based on a summation of various balance types |
| Question: The Bank was informed that for any changes they made to the product conditions, they will need to perform the "proofing and publishing" step. They noticed a field PRODUCT.VERSION in AA.PRODUCT.MANAGER. The value indicated there is 10. If the Bank performs the proofing now, what will be the next value ? |
| 1. 10 | 2. 11 | 3. 10.1 | 4. 10.01 | 5. |
| Answer: 10.1 |
| Question: The Bank has been told that they can create future dated product conditions so that system will update conditions of existing arrangements when 'Tracking' is set. When they looked at the property class record of PAYMENT.RULES, they cannot find the FORWARD.DATED type. They are now complaining to TEMENOS that they have been given wrong information. They said this is because without the FORWARD.DATED type, they cannot create future dated product conditions for Payment Rules. |
| 1. The TYPE 'Tracking' is the one which they should be looking at | 2. The TYPE 'Dated' is the one which they should be looking at | 3. Report as a bug | 4. The TYPE 'Multiple' is the one that they should be looking at | 5. |
| Answer: The TYPE 'Dated' is the one which they should be looking at |
| Question: In the product line record, the Bank sees the description 'LENDING'. They inform us that credit facilities in the Bank are all known as 'Financing' and would prefer if the description is changed. Is there a way to amend that ? |
| 1. No problem, we can change the description of product line from 'Lending' to 'Financing' | 2. TEMENOS has only released LENDING product line. The Bank cannot change that | 3. Descriptions of product lines cannot be changed; however we can create product groups called 'Financing' | 4. Create a new product line with the ID 'Financing' | 5. |
| Answer: No problem, we can change the description of product line from 'Lending' to 'Financing' |
| Question: The Bank wants to control the amount that customer repays the loan within the first 3 years into the contract. The total repayment amount cannot be more than 20% of the loan agreement amount. They want system to calculate this percentage difference and throw an error message if necessary. Is it possible to achieve this ? |
| 1. No, require local development | 2. Yes, create an appropriate periodic attribute using the TRANSACTION.AMOUNT.TOTAL periodic attribute class | 3. Yes, create an appropriate periodic attribute using the TRANSACTION.AMOUNT periodic attribute class | 4. Yes, create an appropriate periodic attribute using the REPAY.TOLERANCE.TOTAL periodic attribute class | 5. |
| Answer: Yes, create an appropriate periodic attribute using the REPAY.TOLERANCE.TOTAL periodic attribute class |
| Question: The Bank wants to impose penalty fee if customers partially withdraw their deposits more than twice within the last full 12 months. What would be the most appropriate periodic attribute to use ? |
| 1. Repeating 1 year Calender | 2. Rolling 1 year Calendar | 3. Rolling 1 year | 4. Repeating 1 year | 5. |
| Answer: Rolling 1 year |
| Question: The Bank has defined the new arrangement fee amount as fully negotiable. However, when users create the new arrangement, they can only view but not able to input a value. What could have happened? |
| 1. Fee calculation source is not defined | 2. Fee condition has been set to Tracking in the product designer | 3. Fee is defined at parent product level, which this product has the 'Inheritance Only' field set to Yes | 4. Minimum and maximum amount negotiation rule has been set in the charge condition | 5. |
| Answer: Fee condition has been set to Tracking in the product designer |
| Question: Bank has created a 3 level product hierarchy - child product, parent product and grandparent product. The same Activity Charges property has product condition defined at both grandparent and parent levels and no specific condition has been stated for the child product for this property. The above hierarchy of products are published. When the arrangement is created for the child, which activity charges condition will the arrangement use ? |
| 1. Activity Charges condition defined at grandparent level | 2. Activity Charges condition defined at both grandparent and parent level | 3. Activity Charges condition defined at parent level | 4. Activity charges would not be applied since it is not defined at the child level. | 5. |
| Answer: Activity Charges condition defined at parent level |
| Question: The Bank typically allows customers to switch products within the Mortgage group during the arrangement lifetime. The product change is mainly for the purpose of re-negotiating the interest rate. Charge amounts remain the same since they are inherited from parent product. Their requirement is that when user inputs the change product request, the interest rate field should clear off old values and it is essential for users to input a new interest rate. For charges, values should remain as original arrangement agreement without the compulsory need for user intervention. What should the Bank do ? |
| 1. In the product condition for Charges, set the DEFAULT.ATTR.OPTION to 'Non-Resetting'. In the product condition for Interest, set DEFAULT.ATTR.OPTION to 'Resetting'. Define the Interest Rate field attribute as Mandatory and Negotiable in NR.OPTIONS | 2. In the product condition for Charges, set the DEFAULT.ATTR.OPTION to 'Resetting'. In the product condition for Interest, set DEFAULT.ATTR.OPTION to 'Non-Resetting'. Define the Interest Rate field attribute as Mandatory and Negotiable in NR.OPTIONS | 3. In the product condition for Charges, set the NR.OPTIONS to 'Non-Resetting'. In the product condition for Interest, set DEFAULT.ATTR.OPTION to 'Resetting'. Define the Interest Rate field attribute as Mandatory and Non-Negotiable in NR.OPTIONS | 4. In the product condition for Charges, set the DEFAULT.ATTR.OPTION to 'Resetting'. In the product condition for Interest, set DEFAULT.ATTR.OPTION to 'Non-Resetting'. Define the Interest Rate field attribute as Mandatory and Non-Negotiable in NR.OPTIONS | 5. |
| Answer: In the product condition for Charges, set the DEFAULT.ATTR.OPTION to 'Non-Resetting'. In the product condition for Interest, set DEFAULT.ATTR.OPTION to 'Resetting'. Define the Interest Rate field attribute as Mandatory and Negotiable in NR.OPTIONS |
| Question: Bank wants to have zero tolerance between the payoff transaction amount and the simulated payoff bill amount. They have defined 2 periodic attribute records using the periodic attribute class PAYOFF.AMOUNT. One is for negative tolerance and another is for positive tolerance. Where should they attach these periodic attribute records to ? |
| 1. PAYOFF product condition | 2. ACTIVITY.RESTRICTION product condition | 3. FT.TXN.TYPE.CONDITION | 4. TERM.AMOUNT product condition | 5. |
| Answer: PAYOFF product condition |
| Question: In the Periodic Attribute record, user saw COOLING-OFF as one of the list of values in RULE.START attribute. How or where does system determine this base date ? |
| 1. From the day arrangement is created | 2. From the day the loan is disbursed | 3. Based on the date calculated from COOLING.PERIOD defined in TERM.AMOUNT product condition | 4. Based on the date calculated from CANCEL.PERIOD defined in TERM.AMOUNT product condition | 5. |
| Answer: Based on the date calculated from COOLING.PERIOD defined in TERM.AMOUNT product condition |
| Question: For a particular product, Bank allows customers to make multiple loan disbursements. How should the Bank set up this product in order to permit this ? |
| 1. No set up is required | 2. Define a periodic attribute record using FULL.DISBURSEMENTperiodic attribute class. Attach this record in the periodic rule and the PR.VALUE is to defined as the disbursement amount allowed | 3. Define a periodic attribute record using TRANSACTION.AMOUNT.TOTAL periodic attribute class. Attach this record in the periodic rule and the PR.VALUE is to be set to the total loan commitment amount | 4. Define a periodic attribute record using FULL.DISBURSEMENTperiodic attribute class. Attach this record in the periodic rule and the PR.VALUE is to be set to NO | 5. |
| Answer: No set up is required |
| Question: The Bank wants to control the number of times that a deposit is being funded. Customers can funding deposits by going to the branch, via internet or remitting money from other financial institutions. The Bank was told that they can make use of the TRANSACTION.COUNT.TOTAL periodic attribute class. What should they do with this periodic attribute class ? |
| 1. Attach this periodic attribute class to the ACTIVITY.RESTRICTION product condition of the deposit. Define the total number of counts allowed | 2. Attach this periodic attribute class to the FT.TXN.TYPE.CONDITION record. Define the total number of counts allowed | 3. Attach this periodic attribute to the ACTIVITY.RESTRICTION product condition of the deposit. Define the total number of counts allowed | 4. Attach this periodic attribute to the ACTIVITY.RESTRICTION product condition of the account. Define the total number of counts allowed | 5. |
| Answer: Attach this periodic attribute to the ACTIVITY.RESTRICTION product condition of the deposit. Define the total number of counts allowed |
| Question: The Bank users are currently using the simulation function to simulate new deposit offerings. They do not execute the simulation though. The users are complaining that there are too many unnecessary fields appearing when they only need to fill in the term and amount for simulation purpose. They would want see and input those extra fields only if a real deposit arrangement is created. Is there anything that can be done ? |
| 1. The same screens are used for both creating real arrangements and for creating simulated arrangements. Hence, there is nothing that can be done | 2. Write a routine to check that whether the arrangement is live creation or just a simulation. Depending on the situation, the routine is to pick the correct version to display | 3. The versions used for live arrangement creation and simulation can be defined in AA.PRD.DES.ACTIVITY.PRESENTATION | 4. The versions used for live arrangement creation and simulation can be defined in AA.PRD.DES.ACTIVITY.MESSAGING | 5. |
| Answer: The versions used for live arrangement creation and simulation can be defined in AA.PRD.DES.ACTIVITY.PRESENTATION |
| Question: There are 3 departments using the AA Loan application. Due to their different job nature in each department, the Bank wants to display different arrangement screen formats to their users. Is this possible using the Activity Presentation product condition ? |
| 1. No | 2. Yes, define the different versions used in the Activity Presentation product condition | 3. Yes, set negotiation rule to YES for the Activity Presentation product condition | 4. Yes, define different named properties for the same product so as to differentiate between the departments. Thereafter, define specific versions for the different properties | 5. |
| Answer: No |
| Question: Bank has included the CHARGE OVERRIDE property in the product. They understand that including this property can allow users to perform fee waiver at the very moment of the arrangement activity. User creates a new arrangement. Aware that this is a special customer, she decides to input a partial waiver of the new arrangement fee. However, she does not see the Charge Override condition appearing and could not input the waiver |
| 1. CHARGE OVERRIDE condition will only appear when user clicks on the COMMIT or VALIDATE button | 2. CHARGE OVERRIDE condition will only appear when the OVERRIDE message generated is accepted | 3. This is not possible. The product designer did not successfully proof and publish this condition | 4. For this product, the CHARGE OVERRIDE product condition has been set to TRACKING or CUSTOM TRACKING | 5. |
| Answer: CHARGE OVERRIDE condition will only appear when user clicks on the COMMIT or VALIDATE button |
| Question: Bank wants a 1% fee to be collected when disbursement takes place. The fee is based on the disbursement amount. A loan has the following information: TOTCOMMITMENT is 100,000 and the disbursement is 20,000. This will make the CURCOMMITMENT become 80,000 and CURACCOUNT will be 20,000. When designing the product, what should be the values of the SOURCE.TYPE and SOURCE.BALANCE ? |
| 1. SOURCE.TYPE is TXN.AMOUNT and SOURCE.BALANCE is TOTCOMMITMENT | 2. SOURCE.TYPE is TXN.AMOUNT and SOURCE.BALANCE is CURCOMMITMENT | 3. SOURCE.TYPE is TXN.AMOUNT and SOURCE.BALANCE is CURACCOUNT | 4. SOURCE.TYPE is TXN.AMOUNT | 5. No definition required |
| Answer: SOURCE.TYPE is TXN.AMOUNT |
| Question: When a customer submits a payment on a loan which has no due amounts, the bank wants to hold the payment (without allocating it to principal, interest or charges) until amounts are actually due. The ACCOUNT record in AA.PROPERTY.CLASS has the following specified in the BALANCE.PREFIX field: CUR, DUE, AGE, UNC and UND. Which of these would be useful in this scenario? |
| 1. DUE | 2. UNC | 3. UND | 4. AGE | 5. This cannot be determined |
| Answer: UNC |
| Question: A consultant successfully proofs and publishes a Retail Accounts product. When he looks for the product in the Product Catalog, he is unable to find it, what could be the reason for this? |
| 1. While designing the product, INHERITANCE.ONLY Field is set as Yes | 2. While designing the product, INHERITANCE.ONLY Field is set as No | 3. While designing the product, a parent product was omitted to be added in PARENT.PRODUCT Field | 4. While designing the product, the DEFAULT.PRODUCT Field was marked as No | 5. While designing the product, the DEFAULT.PRODUCT Field was marked as Yes |
| Answer: While designing the product, INHERITANCE.ONLY Field is set as Yes |
| Question: The Bank created a deposit product with restrictions on the number of partial withdrawals. Customer is not allowed to withdraw the deposit partially more than once a year. The Bank defined an appropriate periodic attribute record with DATE.TYPE defined as CALENDAR and PERIOD defined as 1Y. For a particular arrangement, a partial withdrawal on 20 May 2013 was performed. On 3 Jan 2014, the user tries to perform the second partial withdrawal. Will the second withdrawal transaction succeed ? |
| 1. No | 2. Yes | 3. No, if we define RULE.START as COOLING-OFF | 4. Yes, if we define PERIOD.TYPE as LIFE | 5. |
| Answer: Yes |
| Question: Which core table related to statements will be updated with the fields values from AA statement property class? |
| 1. STMT.GEN.CONDITION | 2. AC.STMT.PARAMETER | 3. ACCOUNT.STATEMENT | 4. ACCT.STMT.PRINT | 5. |
| Answer: ACCOUNT.STATEMENT |
| Question: Choose the correct answer related to the file AA.ACCRUAL.FREQUENCY |
| 1. The file AA.ACCRUAL.FREQUENCY allows the user to define the frequency for interest and charge accruals specific to company or for the whole system | 2. The file AA.ACCRUAL.FREQUENCY allows the user to define the frequency for interest accruals specific to company or for the whole system | 3. The file AA.ACCRUAL.FREQUENCY allows the user to define the frequency for interest accruals specific for the whole system | 4. The file AA.ACCRUAL.FREQUENCY allows the user to define the frequency for interest and charge accruals specific for the whole system | 5. |
| Answer: The file AA.ACCRUAL.FREQUENCY allows the user to define the frequency for interest accruals specific to company or for the whole system |
| Question: Which of the following files are updated during accrue activity |
| 1. AA.INTEREST.ACCRUALS | 2. AA.PROCESS.DETAILS | 3. AA.ACTIVITY.HISTORY | 4. AA.ACCOUNT.DETAILS | 5. A & B |
| Answer: AA.INTEREST.ACCRUALS |
| Question: A consultant is designing a Student Loan Product which belongs to the Personal Loans Product Group. She includes a Loan Interest Property which belongs to the Interest Property Class and wants to levy interest only if the interest calculated for that bill is more than 1 OS- Which field(s) in AAPRD-DES.INTEREST has to be updated by her compulsorily to achieve this functionality? |
| 1. MIN.INT.AMOUNT | 2. MIN.INT.WAIVE | 3. MARGIN.RATE | 4. Both (a) and (b) | 5. |
| Answer: Both (a) and (b) |
| Question: For an AA balance types(Except Accrual Balance), what would be the appropriate value for the field Activity Update(ACTlVlTY.UPDATE in AC.BALANCE.TYPE) |
| 1. Always set as No | 2. All the AA processing would be depend on the values in ACCT-BALANCEACTIVIW table- Hence it should be set as Yes for all balances. | 3. This field only deal with ACCTACTIVITY. Hence it is not related to AA | 4. All the AA processing would depend on the values in the table ACCT.BALANCE.ACTIVITY. Hence it should be set as Yes. But we can switch-off(Set as No) this flag for accrual balances. | 5. |
| Answer: This field only deal with ACCTACTIVITY. Hence it is not related to AA |
| Question: What is the recommended way of defining an Integration exit point for AA? |
| 1. Exit point based on AAACTIVITY.CLASS / AAACTIVITY | 2. Exit point can be defined based on component service | 3. Exit point can be defined based on VERSION | 4. Exit point can be defined based on AAARRANCMENTACTIVITY | 5. |
| Answer: Exit point based on AAACTIVITY.CLASS / AAACTIVITY |
| Question: Bank wants to configure new interest properties to an existing Loan Product but does not want to create all balance type and activities manually, How to achieve this? |
| 1. Set REBUILD.ACTIVITIES in AA.PRODUCT.GROUP | 2. Set REBUILD.BALANCE.TYPE and REBUILD.ACTIVITIES in AA.PRODUCT.GROUP | 3. It is possible to auto create activities alone but not balance type. | 4. Set REBUILD.ACTIVITY.BALANCE in AA.PRODUCT.GROUP | 5. |
| Answer: Set REBUILD.BALANCE.TYPE and REBUILD.ACTIVITIES in AA.PRODUCT.GROUP |
| Question: User created the simulation for an activity LENDING-UPDATE-ACCOUNT and moved the corresponding simulation into LIV. Now In which table the LIV account record will be stored |
| 1. AA.PRD.CAT.ACCOUNT | 2. AA.ARR.ACCOUNT | 3. AA.ARR.ACCOUNT$SIM | 4. AA.SIM.ACCOUNT | 5. |
| Answer: AA.ARR.ACCOUNT |
| Question: The User wants to do a change interest and does this using a zero auth version. However as the user does not have privileges to approve the overrides, the change interest AAA is moved to INAO status. What will be the status of any existing child transactions for the change interest activity? |
| 1. As the AAA iS in INAO, the resultant child transactions will also be in INAO. | 2. As the AAA is in INAO, the resultant child transactions will not be created | 3. Since it is zero auth version, the child transaction Will be authorized. | 4. As the AAA is in INAO, the resultant child transactions will be in INAU. | 5. |
| Answer: As the AAA iS in INAO, the resultant child transactions will also be in INAO. |
| Question: During back dated Rate Change bank want to reverse the Auto settlement made on the settlement account and then the Auto settlement needs to be replay based on new amount after the new rate has been applied. How the bank will enable this behavior to all his products. |
| 1. Set AUTOMATIC in RECONSTRUCT.SETTLEMENT field in to AA.PARAMETER | 2. Set Yes in RECONSTRUCT.SETTLEMENT into AA.PARAMETER | 3. No setup required, the current system behavior will stratifies the bank requirements. | 4. RECONSTRUCT.SETTLEMENT is a no change field so include all the required product groups into to EXCLUDE.GROUP in AA.PARAMETER | 5. |
| Answer: Set AUTOMATIC in RECONSTRUCT.SETTLEMENT field in to AA.PARAMETER |
| Question: Bank wants to capture a customer who is not a legal owner for an arrangement. In T24 which field is used to capture those information. |
| 1. OWNER in Arrangement Activity | 2. OTHER.PARTY field in Customer Application | 3. OTHER.PARTY field in Customer Property Class | 4. OWNER field in Customer property Class | 5. |
| Answer: OTHER.PARTY field in Customer Property Class |
| Question: Choose the most appropriate statement about product currency(CURRENCY in ARPRODUCT.DESIGNER) in AA for an active product which has active arrangements under all of its applicable currencies |
| 1. We can modify the product currency at any time | 2. Product currency can be added at any time | 3. Input in this field is mandatory only for financial products | 4. B & C | 5. |
| Answer: Input in this field is mandatory only for financial products |
| Question: A user is trying to proof a product. While proofing the product the system raises error and prompts the user to setup DAILY.ROUNDING as YES for the interest property. How to resolve is the significance of this setup? |
| 1. Setup the daily rounding in product group. | 2. This can be resolved by properly configuring the source calc type table. | 3. This can be resolved by setting DAILY frequency in the AA accrual frequency table. | 4. This can be resolved by setting DAILY-ROUNDING as YES in the Accrual param table. | 5. |
| Answer: This can be resolved by setting DAILY-ROUNDING as YES in the Accrual param table. |
| Question: In the Activity Restriction property, the values in PERIODIC.RULE are valid entries from which table. |
| 1. AA.PERIODIC.ATTRIBUTE | 2. AA.PERIODIC.RULE | 3. PERIODIC.RULE.CATALOG | 4. AA.PERIODIC.RULE.DEFINITION | 5. |
| Answer: AA.PERIODIC.ATTRIBUTE |
| Question: Is it possible to restrict conditions associated with some of the properties at Parent product not to be overwritten at child product? |
| 1. By setting PROPERTY.INHERITANCE to Lock in AA.PRODUCT.DESIGNER | 2. By setting PROPERTY.TYPE as INHERITANCE.ONLY in AAPROPERTY | 3. By Setting INHERITANCE.ONLY as YES in AA.PRODUCT.DESIGNER | 4. Not possible | 5. |
| Answer: By setting PROPERTY.INHERITANCE to Lock in AA.PRODUCT.DESIGNER |
| Question: A bank want to set up loan with fixed rate for first 3 years and then variable. How to configure this in AA product level |
| 1. Through the local customization(By attaching routine) we can modify the rate from Fixed to Variable after 3 years | 2. Create two condition one for fixed and another one for variable. For an interest property attach both condition and set Effective as 3Y | 3. For a same condition input both fixed and BI/PI setup together | 4. It is not configurable in AA | 5. |
| Answer: Create two condition one for fixed and another one for variable. For an interest property attach both condition and set Effective as 3Y |
| Question: The flag "Rebuild Activities" at the product group allows the rebuilding of activities when either there is a new property that is introduced into the group or a new activity class is introduced. |
| 1. TRUE | 2. FALSE | 3. | 4. | 5. |
| Answer: TRUE |
| Question: For a deposit arrangement interest payout happen to the customer savings account every month. After interest payout, if there any back dated rate change happen client want to reverse the current payout amount from savings account and the new interest payout amount based on the new rate. But client want this behavior only for a specific product alone. How can we achieve this functionality |
| 1. Yes. RECONSTRUCT.SETTLEMENT as null and specify product into EXCLUDE.GROUP in AAPARAMETER | 2. Yes. Specify the product into the field RECONSTRUCT.SETTLEMENT in AAPARAMETER | 3. Yes. RECONSTRUCTSETTLEMENT as AUTOMATIC and specify product into EXCLUDE.GROUP in AAPARAMETER | 4. We can't restrict to a specific product | 5. Yes. RECONSTRUCTSETTLEMENT as AUTOMATIC and specify product into EXCLUDE-GROUP in ACCOUNT-PARAMETER |
| Answer: |
