Negotiation Income Indicator

Income Value Logic  Income Calculation Logic ▫The income value will need re-calculating if an adjustment has been made to the offer ▫The Income calculation will be part of a Model Call to Model Manager ▫The Income Calculation logic will be hosted within a dedicated Income Model − Will require a sequential call to the Income Model after the Finance model has been called ▫Income Model inputs (Pricing Team have indicated circa 10 fields are required) − Payment Method, Add-ons Selected, Net Price, Gross Price, Total Discount, Total Cashback, + others tbc) ▫Income Model Outputs − ‘Income Value’ Output(s) 2

Single Income Value 3 Single Income Displayed Alternate Styling

Single Income Value Supporting Logic  If only a Single Income Value is required then: ▫A call is required to the Income Model after the Finance Model has been called ▫Income Model inputs: − Payment Method, Add-ons Selected, Net Price, Gross Price, Total Discount, Total Cashback, + others tbc) ▫Income Model Outputs: − Single ‘Income Value’  Assumption ▫Income is calculated and displayed based on the: − preference indicated earlier in the risk capture for Annual vs Monthly payments − the onscreen selected adjustment Cashback or Discount  Screen Changes ▫Less screen real estate required for single value so simpler to accommodate  Trigger event ▫Finance Model results have been returned 4

Independent Income Value for C/b & Discount 5 Income Displayed Alternate Styling

Income Value for C/b & Discount Supporting Logic  If an Income Value is required for both Discount and Cashback then: ▫A call is required to the Income Model after the Finance Model has been called ▫Income Model inputs below are required for both Cashback and Discount Values: − Payment Method, Add-ons Selected, Net Price, Gross Price, Total Discount, Total Cashback, + others tbc) ▫Income Model Outputs: − ‘Income Value’ for Cashback − ‘Income Value’ for Discount  Assumption ▫Income is calculated and displayed based on the: − preference indicated earlier in the risk capture for Annual vs Monthly payments  Screen Changes ▫Moderate real estate impact required for displaying two values with an additional column required on the popup  Trigger event ▫Finance Model results have been returned 6

Income Displayed Alternate Styling Four Income Values C/b, Discount, Annual & Monthly 7

Income Value for C/b, Discount, Annual & Monthly Supporting Logic  If an Income Value is required for both Discount, Cashback then: ▫A call is required to the Income Model after the Finance Model has been called ▫Income Model inputs below are required for both Annual Cashback, Annual Discount, Monthly Cashback and Monthly Discount Values: − Payment Method, Add-ons Selected, Net Price, Gross Price, Total Discount, Total Cashback, + others tbc) ▫Income Model Outputs: − ‘Income Value’ for Annual Cashback − ‘Income Value’ for Annual Discount − ‘Income Value’ for Monthly Cashback − ‘Income Value’ for Monthly Discount  Assumption ▫Income is calculated for all variation on screen  Screen Changes ▫Moderate real estate impact required for displaying four values with an additional row required on the popup  Trigger event ▫Finance Model results have been returned 8

Assumptions  There is no further MI requirement for Negotiation Income  There are other Change Requests being discussed that could influence the design considerations detailed above, these have not been reflected in the above design and logic  The Finance Model is required to return its results before the Income Model can be called. This will impact processing time. ▫If this is not the case then the Income Model can be called in parallel to the Finance model. The Trigger for this is when: − If an adjustment has been made and no further adjustment has been made for 3 seconds (current logic for Finance Model call) 9