ALLFINANZ NOVA Service Level Agreement
2. Support Dates.
3. Maintenance and Support Scope.
Supplier may provide Service Updates or other Maintenance and Support Services to the Hosted Services as and when required at its discretion. The Supplier will liaise with the Customer and schedule the Service Updates in consultation with the Customer. At a minimum, the Customer agrees to accept a Service Upgrade to the Hosted Services at least once every two years to the current applicable version. The Service Updates shall where necessary include the supply to the Customer of all revisions to the Documentation which is necessary in order to reflect any such Service Update provided to the Customer. Service Updates shall not degrade functionality or performance of the Hosted Services.
The Maintenance and Support Services shall be provided during the time frames set out in this Schedule and shall comprise: (a) secure access to the Supplier’s support portal for issue tracking (the “Incident Tracking System”); (b) diagnosis and, where possible, correction of Service Errors or the provision of workarounds in accordance with the Service Levels set out in this Schedule; and (c) the Supplier’s discretion, issue of emergency Service Updates.
Support for any other systems is not in scope. For the avoidance of doubt no support is provided relating to provisioning of internet or intranet access to the Services from Customer environments, issuing of credentials to individual Customer staff, providing consultancy or general advice or trouble-shooting individual end-user system configuration.
The Supplier will be the main support contact for Predictor technology related issues. If the Supplier determines the issue relates to the predictive model itself, the Supplier shall update the Customer and it will be the Customer’s responsibility to the resolve the issue with the builder of the predictive model. However if the builder of the predictive model is Münchener Rückversicherungs-Gesellschaft A.G. (“Munich Re”), the Supplier shall update the Customer and forward or triage the issue to Munich Re directly. Supplier may reasonably adjust the scope and manner of delivery of the Maintenance and Support Services provided that the change does not result in any material degradation in the performance or functionality of the service, or otherwise is to the detriment of Customer.
Maintenance and Support Services will be provided with respect to both the production environment and test environment except that the service level response and resolution times shall only apply in the live production environment.
Rulebook Access. Supplier may access Customer’s rulebook in the Hosted Environment in order to provide Maintenance and Support Services to Customer.
4. Severity Levels.
|Incident severity level||Definition|
|1||Major Service impacting Incident. A technical problem for which there is no available workaround. The problem causes total interruption of the Hosted Services or so substantially impairs the performance of the Service that it is unusable. Example: System non-availability to all users.|
|2||Service functionality is disrupted but workarounds are available where such workarounds can be implemented such that Customer is able to materially carry-on its business that depends on the Service without (i) unreasonable excess cost or (ii) material regulatory or legal risk. Example: The API call to external vendor is not working. For example, where calls to Third Party Data Provider fail due to a problem with Supplier software. Workaround: Temporarily access the vendor site manually.|
|3||Partial or limited loss of non-business-critical functionality. Example: Screen object placement issues, typos, incorrect tool-tips.|
|4||Non-service-impacting problems. Incidents that do not fall under the other categories. Example: Documentation errors.|
5. Support Coverage Windows
|Incident Severity||Support coverage window|
|Severity 1 Hosted Services excluding Insight Analytics, Rulebook Hub and Predictor Vision.||Provided 24/7 unless otherwise agreed by the Parties.|
|Severity 2, 3 & 4 Hosted Services excluding Insight Analytics, Rulebook Hub and Predictor Vision.||Provided during Normal Business Hours on Business Days in the Territory (other than a Saturday, Sunday, public holiday or bank holiday in the Territory) unless otherwise agreed by the Parties.|
|Severity 1, 2, 3 & 4 Insight Analytics, Predictor Vision and Rulebook Hub.||Provided during Normal Business Hours on Business Days in Ireland unless otherwise agreed by the Parties.|
6. Incident Reporting Procedure.
The Supplier shall provide the Customer with a single secure log-in and password to its Incident Tracking System, five concurrent users can log a ticket at any one time. This is for the purpose of logging potential issues, queries and change requests.
Notification of an Incident shall be made by logging into the Incident Tracking System, and opening a new issue and providing all information reasonably required by the Supplier to diagnose the Incident, including without limitation the following basic information relating to Incident unless waived in whole or in part by the Supplier from time to time.
Indicative List of Incident Information. The following is an indicative list of the information that Supplier will typically require to resolve an Incident. Supplier will not necessarily require all such information; the exact details required will vary on a case-by-case basis; the Supplier will request information relevant to the specific Incident:
(a) A description of the problem including any unusual conditions, Incident occurrence and business impact;
(b) Recreation steps;
(c) User ID of the user who experienced the problem;
(d) Data input/imported before the Incident, if any;
(e) Response expected if there was no problem;
(f) XMLs and screen shots (where possible/appropriate);
(g) User environment (desktop OS, browser version);
(h) Business impact of the problem;
(i) Number of users affected, if known;
(j) How long the Incident has been occurring;
(k) Frequency of the Incident;
(l) Any special configurations or conditions;
(m) Any non-standard activity also occurring at the time (e.g. systems being audited, upgraded, general network connectivity issues, only impacting home-workers).
No Personal Data shall be included in the above information.
For the avoidance of doubt, the Supplier shall have no obligation to (i) provide the Services in relation to an Incident which are not demonstrable by the Customer at the time of notification of the Incident and reproducible on a Supplier test system; or (ii) provide Maintenance and Support Services on-Site at Customer’s premises.
Where Incidents are not demonstratable by the Customer, the Supplier shall nonetheless investigate with a view to resolving the Incident. However, in such case, the Service Levels shall not apply until the Service Error has been determined or where demonstrated by the Supplier.
7. Incident Processing
- Upon receipt of notification of an Incident a ticket will be raised in the Incident Tracking System. The ticket will be assigned to a support engineer who will perform an initial triage of the Incident and assign an appropriate Severity Level. In the event that the Customer is not in agreement with the Severity Level assigned, the Customer may trigger the escalation process in accordance with section 14 of this schedule.
- The person raising the ticket will receive an acknowledgement that an Incident has been raised. As part of the investigation the Supplier may request additional information. The Customer shall respond promptly to any such requests and any delay by the Customer in responding will be taken into account when assessing achievement of the Service Levels. For the purpose of the Service Levels, time will start to run from the time and date of the Supplier’s automated acknowledgement of receipt of the ticket. The clock will stop for the purpose of the Service Levels while a response from Customer to Supplier’s request for further information is pending.
- For the avoidance of doubt, Incidents are applicable to all environments (testing, staging and production) except that the service level response and resolution times shall only apply in the production environment only.
- If insufficient information is provided to allow the Supplier assess the Incident then the Supplier will revert on the Incident Tracking System to the person who raised the Incident for clarification. It is important that the person who raised the Incident responds promptly to any information or clarification request.
- If, after 3 attempts to obtain required information within 2 Business Days, the Supplier has not been able to gather sufficient information to proceed (i.e. Customer not-reachable or customer contribution not fulfilled) the Incident will be marked as resolved. Notwithstanding, Customer may request a reasonable extension of time to provide information in regard to a Severity 3 or Severity 4 Incident. The Customer can create a new Incident ticket at any time.
- Supplier will proceed to investigate the Incident in accordance with the Severity Level assigned.
- Incidents with higher Severity Levels will always take precedence over lower Severity Levels unless jointly agreed otherwise.
- Note that Incidents of Severity Level 1 may cause other Incident processing to be suspended until the Severity Level 1 Incident is resolved.
- If the Supplier’s investigations confirm that there is not a Service Error in the Hosted Services, in consultation with the Customer, the issue will be closed in the Incident Tracking System and the Customer will receive an automated update.
- Service Error corrections will normally be delivered as part of a Service Update, release of Documentation or updates to the Services.
- If, after consultation with the Customer, the Customer wishes the Supplier to continue investigation this will be undertaken solely at the discretion and timing of the Supplier and will be a chargeable activity outside the scope of the Maintenance and Support Services (for example, in the event that Customer’s request exceeds the scope of the support services, e.g. configuration change or where request relates to Customer business objectives as opposed to system support, such as a follow-up audit request). Customer and Supplier will mutually agree the closure of a Service Error.
8. Incident Tracking & Receiving Updates.
9. Incident Response and Resolution Times.
Table A: Underwriting Engine and Predictor Connect - Service Levels
|Severity||Maximum Expected Response Time||Target Resolution Time|
|1||1 hour||4 hours|
|2||1 Business Hour||2 Business Days|
|3||4 Business Hours||8 Business Days|
|4||8 Business Hours||Next Service Update, or jointly agreed date.|
Table B: Insight Analytics, Predictor Vision and Rulebook Hub - Service Levels
|Severity||Maximum Expected Response Time||Target Resolution Time|
|1||1 Business Hour||4 Business Days|
|2||1.5 Business Hours||8 Business Days|
|3||4 Business Hours||12 Business Days|
|4||8 Business Hours||Next Service Update, or jointly agreed date|
Table C: Predictor Cloud - Service Levels
|Severity||Maximum Expected Response Time||Target Resolution Time|
|1||4 Business Hours||2 Business Days|
|2||4 Business Hours||4 Business Days|
|3||4 Business Hours||8 Business Days|
|4||8 Business Hours||Next Service Update, or jointly agreed date|
Predictor Cloud: In the event of the Customer reporting an Incident or error with the deployed models on Predictor, the Supplier shall use the test data provided by the Customer to run comparisons against the original benchmark output data to validate consistency of technology performance and operation. It is the Customer’s responsibility to resolve any errors in the predictive model itself directly with the model builders.
The target times set forth in the above tables exclude the time required to execute the standard regression test. Not all resolutions will require regression testing and the extent of such tests, when required, will be limited to the areas impacted, with the Customer being informed of the expected duration.
Supplier shall use reasonable endeavours to meet the Service Levels. If the Supplier fails to meet the target time for Severity Level 1 or Severity Level 2, the Supplier shall continue to work on the issue per the support coverage windows set out in Section 5 of this Schedule until the Service Error is corrected or a workaround is provided or the Service Error is reduced to a lower Severity Level.
Where a Severity Level 4 Service Error is to be corrected in a future Service Update, then for a reasonable period prior to the issue of such Service Update the Supplier shall be entitled to decline to provide assistance in respect of that Severity Level 4 Service Error.
If the Severity Level of an Incident is reduced, the Service Levels for the new reduced Severity Level will apply.
Response Time is the time it takes to acknowledge a Customer's issue in a non-automated way. It is measured from the time an Incident record is created, either by the Customer or by the Supplier manually creating a record, until the time that the Customer is advised their problem has been received and is being addressed.
Resolution Time is the time it takes to resolve a Customer’s issue or to answer their question. It is measured from the time an Incident is automatically acknowledged following the reporting of the incident on the Incident Tracking System and shall run until the time that the Customer is advised that the Service Error has been resolved. The Incident may be marked as resolved through providing a work-around, fixing any underlying issue or by deeming that support for the Incident is no longer needed because it is a duplicate, cannot be reproduced or there is insufficient information to continue investigating the issue or the Customer has not responded to information requests. Support service targets are defined as:
|Severity||Response Time target||Resolution Time target|
|1||90% of Incidents managed within expected time during a reporting period.||90% of Incidents managed within expected time during a reporting period.|
10. Incident Recovery.
Supplier will make reasonable efforts to resolve Incidents within the given resolution times. Individual Incidents may involve considerable effort to investigate and diagnose so Supplier may offer interim solutions or solutions which provide other paths to solve the underlying business need. Provision of processes or solutions which recover the system to a usable form but involve new or additional flows or Customer processes to which Customer agrees (Customer will not unreasonably withhold agreement), will be deemed to have resolved the Incident.
Where an Incident is marked as resolved due to the Customer not responding or being unavailable, the Incident will not be included for the purposes of calculating resolution times as the support clock will have been paused.
Where the processing of an Incident has been suspended because of Customer request, or because a Severity Level 1 Incident has occurred and taken precedence, then the support clock for the lower severity Incident will be stopped.
11. Metrics & Reporting.
12. Service Continuity and Disaster Recovery.
In the event of a major service outage due to circumstance beyond the reasonable control of the Supplier then the Support service will be suspended and effort will be diverted towards the restitution of the Service.
Once the Service has been restored Maintenance and Support Services will resume, however the Service support clocks will be treated as stopped for the purposes of calculating response and resolution times until such time as the outage has been resolved. Uptime and availability metrics will exclude time when the Hosted Services were not available or were in the process of being restored to operation due to a major service outage beyond the reasonable control of the Supplier or due to Force Majeure events or caused by third party actions or Customer systems.
13. Service Availability.
|Service||Service Availability||Basis for measurement|
|Underwriting Engine, Predictor Connect and Predictor Cloud||99.70% uptime||Pings each minute of the service|
|Rulebook Hub, Insight Analytics and Predictor Vision||95.00% uptime||Hourly pings of the service|
Measurement will be based on time taken for the service to process each request, processing up to 1,200 cases per hour, against the standard ruleset.
Service Availability measurement excludes time when the Service is not available due to Scheduled or Unscheduled Maintenance, major outages due to events beyond the reasonable control of the Supplier, Service suspension at Customer request, Interruptions due to Customer technical or network connectivity issues or actions by third parties acting on behalf of the Customer, Service issues due to Customer or use by parties other than Permitted Third Parties or use of the Hosted Services outside agreed Service limits.
14. Escalation Procedures.
In the event that the Customer wishes to escalate an Incident then they must contact their account manager. The escalation process does not suspend any on-going support process but will trigger a request for a review of the severity categorisation of an Incident. If jointly agreed, then the Incident will be reclassified and managed with the new severity rating.
Any reporting metrics on Incident processing will reflect the original Severity Level of the Incident until the time and date of any change for the purposes of calculation.
15. Scheduled Maintenance.
|Server Location||Applicable Time Zone|
|Australia||Australian Eastern Standard Time|
|Canada||Canadian Eastern Daylight Time|
|European Union||Irish Standard Time|
|Singapore||Singapore Standard Time|
|U.S.A.||Eastern Standard Time (USA)|
Notice of Scheduled Maintenance times will be given to the Customer by the Customer Account Manager. This timing will be aligned as much as reasonably possible to Customer preferences.
A Scheduled Maintenance notice will be displayed where reasonably practical on users’ web screens (if any) or the Customer will need to undertake to inform its users of the Scheduled Maintenance.
Scheduled Maintenance shall not count as downtime/ service interruption. The Support processes, Severity Levels and Incident response times, resolution times and service availability as described in this schedule or the Agreement do not apply when the Hosted Services are in Scheduled Maintenance mode.
When the Scheduled Maintenance does not require complete shutdown of the Service the Customer may be advised with reasonable notice and as far as practicable what Service functionality is usable and what Service limitations may be imposed during the period of Scheduled Maintenance.
16. Unscheduled Maintenance.
17. Extraneous Factors.
Services may not be available or may be degraded arising from any of the following: —
(a) Failure by the Customer to use the Services in accordance with the Documentation or instructions of the Supplier or strictly within the scope of this Agreement;
(b) Use by the Customer of any configurations outside the Hosted Services platform that have not been prior approved by the Supplier that affects the Services;
(c) The occurrence of any event of force majeure;
(d) The malfunction or failure of equipment or infrastructure applications, content, scripting or coding owned or sourced by the Customer that are used with the Services; the failure of public utilities and similar equipment/infrastructure;
(e) Any errors, acts or omissions by the Customer or the Customer’s systems (including web browsers) that inhibit or prevent the delivery of the Services by the Supplier;
(f) Unavailability or degraded performance of the Customer’s network or IT infrastructure;
(g) Suspension to implement any service-related installation or configuration requested by the Customer and agreed to by the Supplier;
(h) Any degraded service or suspension in delivery of service by Third-Party Data Providers or Third-Party Service Providers (except for Supplier’s sub-contractors);
(i) Any unremedied material breach by the Customer of its licensing and subscription obligations under this Agreement;
(j) Suspension or termination of service in accordance with the terms of this Agreement;
(k) The directions, instructions, orders of any regulator or law enforcement authority of competent jurisdiction;
(l) Incidents that are not demonstrable by Customer at the time of notification of the Incident and not reproducible on a Supplier hosted test system despite having made reasonable efforts to replicate the conditions that resulted to the particular Incident; or
(m) faults in any of Customer’s third-party environmental software on which the Services are dependant (including without limitation operating systems, application servers, databases, webservers or browsers).
Suspension of service due to the any of the above events or circumstances shall not count as downtime/service interruption;
18. Process Review and Change Control.
19. Customer Internal Duties.
Customers are required to: -
- Maintain a contact person in the role of Service Owner for communications and escalations and make sure their notified contact details are up to date;
- On raising Incidents to provide as much information as possible to help Incident investigation; and
- Triage Incidents before contacting the Supplier to validate that the issues relate to the Supplier Hosted Service and are not due to other non-Supplier supplied services or internal technical or non-technical issues.
20. Service Limits.
21. Service Quality Credits.
If Service Availability for the Hosted Services (excluding Rulebook Hub, Insight Analytics and Predictor) falls below the Service Availability target in a given calendar month, the Supplier shall credit the Customer's account by an amount calculated as the product of the total cumulative downtime minutes (expressed as a percentage of the total possible uptime minutes in the month concerned) and the total annual Base Platform Fee pro-rated for that calendar month.
A Service Credit shall not be payable unless the Customer requests it within 30 calendar days of the service-affecting event(s). The maximum Service Credit allowable in a given calendar month is limited to 7.5% of the Base Platform Fee pro-rated for that calendar month or EUR 1,000, whichever is the lower.
No other penalty, rebate, refund or fee will apply for Service non-availability.
22. Chronic Failures.
22.1 In this schedule the term “Chronic Failure” means:
(a) the occurrence of three or more Severity Level 1 or Severity Level 2 Service Errors arising in respect of the Hosted Services within a six (6) month period that are not resolved by the Supplier within the agreed timeframes set out in this Schedule (each such occurrence being a “Service Error Incident”) or;
(b) the failure by the Supplier to achieve one or more of the Service Availability targets for Hosted Services (excluding Insight Analytics, Rulebook Rub and Predictor) for three or more months within a six (6) month period (each such occurrence being an “Availability Incident”) or;
(c) a combination of three or more Service Error Incidents and/or Availability Incidents within a six-month period.
22.2 Should a Chronic Failure occur during the Subscription Term THEN the Customer shall notify the Supplier in writing that a material breach of contract by the Supplier has occurred. In such event, the Customer may, but shall not be obliged, to initiate the Dispute Resolution Procedure and if unresolved pursuant to the conclusion of that procedure, then the Customer may terminate this Agreement upon written notice to the Supplier and receive a refund of any pre-paid Subscription Fees in respect of the Hosted Services forward from the date of termination.