The instrument organizes data collection around a single reporting form LOLRF 800.1 and a detailed record layout (Policy Data Specifications). Core concepts in the document are explicit and operational rather than high-level policy.

Reportable policy: Defined in paragraph 16. It covers insurance policies entered into on or after 1 January 2003 of product liability, professional indemnity, or public liability insurance. The definition expressly excludes reinsurance or retrocession, marine insurance, domestic householder/owner policies sold with building or contents policies, and policies solely for events that could neither occur in Australia nor in relation to an insured resident of Australia (paragraph 16, “reportable policy”).

Reporting period and due date: Default reporting cadence is calendar half-yearly (30 June / 31 December) with data due no later than four months after the end of the reporting period (paragraphs 6 and 8(a)). APRA may vary reporting periods, frequency or basis in writing having regard to particular circumstances (paragraph 7). Paragraph 17 clarifies that Lloyd’s must ensure APRA or its agent actually receives the information by the required date.

Submission format and security: Data must be rendered as CSV per LOLRF 800.1 instructions and submitted electronically via www.ncpd.apra.gov.au using credentials provided by Fujitsu Australia (agent of APRA) (paragraphs 9 and 12). A secure session and encryption are required upon successful validation of credentials (paragraph 12).

Data content and field-level rules: The Record Layouts set mandatory fields (marked M), optional fields (O) and “T” fields requiring at least one populated value (see the Policy Data Specifications table). Dates must be DDMMYYYY with no delimiter. Currency conversion and treatment of statutory charges (FSL, GST & SD excluded) are specified for premium fields. Certain field combinations must be unique per reporting period (fields marked with an asterisk) and endorsement/cancellation reporting rules require separate records for exposures before and after the change (see Appendix B and the record definitions).

Internal controls and authorisation: Lloyd’s must develop appropriate processes and controls for internal review and authorisation of the information (paragraph 11). An authorisation regime is described: Fujitsu provides a customer ID and password, Lloyd’s must apply for a password via the specified web page, and APRA may determine that specified persons or positions may authorise submissions (paragraphs 12-13).

Data validation and reconciliation: APRA will validate submitted policy data against Lloyd’s aggregate figures, expecting earned premium to reconcile within 5% to the aggregate earned premium reflected in Lloyd’s accounts or as calculated by APRA from gross annualised premium (Appendix A). APRA expects Lloyd’s to explain discrepancies above this threshold and to share additional information as required (Appendix A).

Variability and change control: APRA reserves the right to make minor variations to LOLRF 800.1, including correcting technical or logical errors, varying or substituting occupation codes in Appendix B, or varying table specifications where APRA forms a view changes are appropriate, and must notify Lloyd’s in writing of such variations (paragraphs 14-15).

Primary obligated party: Lloyd’s. The Standard applies to Lloyd’s (paragraph 3) and repeatedly addresses “Lloyd’s” responsibilities (paragraphs 5, 9-13). It requires information in respect of each reportable policy of a Lloyd’s underwriter in force during the reporting period (paragraph 5).

Lloyd’s underwriters and market participants: While the legal obligation is on Lloyd’s, the reporting content is per-underwriter policies and exposures (paragraphs 5 and the Record Layouts). The Record Layouts require Lloyd’s to report its proportion (coinsurance proportion) of premiums, limits, and other items (field 23 and field definitions). Where Lloyd’s participates in a risk only as a share, the coinsurance proportion and the Lloyd’s share of premiums and limits must be reported (field definitions at 15a, 15b, 16 and 23).

Agents and service providers: Fujitsu Australia is named as APRA’s agent for data receipt and credential management (paragraphs 9 and 12). The Standard contemplates APRA making determinations to require submission by other methods or to other agents (paragraph 10). APRA may also authorise particular persons (not necessarily Lloyd’s General Representative or agent) to authorise data submissions (paragraph 13), so third-party IT or reconciliation providers may be operationally engaged.

Internal Lloyd’s personnel: Lloyd’s General Representative in Australia has specified functions including ensuring policies and procedures for data authorisation are in place (note to paragraph 11; paragraph 12 mentions notification to Lloyd’s General Representative of the password). Paragraph 13 contemplates APRA can specify who may authorise submissions.

Data users: APRA will use the data for prudential supervision and publication including the NCPD (paragraph 2). The Record Layouts state that policy numbers (field 7) are used only for cross-referencing by APRA and will not be published except in individual data reports prepared for the insurer concerned (field 7 explanation).

Insureds and intermediaries: The Standard indirectly affects brokers and policyholders because the Record Layouts require use of broker market references (policy and risk numbers, fields 7 and 8). The Record Layouts also require classification of insured organisations by ANZSIC or APRA occupation codes, which may require underwriters and brokers to collect or reconcile classification data when policies are written or endorsed.

Excluded classes and transactions: The reporting obligation excludes reinsurance and retrocession, marine insurance, domestic householder/owner policies sold with building/contents, and policies solely concerning events that could not occur in Australia or to Australian residents (definition of reportable policy, paragraph 16).

APRA and regulators: APRA is both the recipient and the decision-maker for variations, validations and notice-making (paragraphs 7, 10, 14-15), and the Standard relies on APRA’s discretion in several operational areas.

Who bears costs: The reporting burden , data extraction, conversion to CSV, mapping to required codes (ANZSIC 4-digit or APRA occupation codes in Appendix C), currency conversions, reconciliation to Lloyd’s accounts and establishing internal authorisation processes , falls primarily on Lloyd’s and any agents it engages. The Standard also prescribes use of Fujitsu’s portal and credentials which implies operational costs associated with system access and security.

Duties imposed on Lloyd’s:

• Provide the information required by LOLRF 800.1 for each reporting period and each reportable policy in force during the reporting period (paragraph 5).
• Submit data at the default half-yearly frequency unless APRA determines otherwise (paragraphs 6 and 7).
• Ensure submission in CSV format in accordance with LOLRF 800.1 and via the specified secure web portal unless APRA determines alternative requirements (paragraphs 9-10, 12).
• Ensure internal processes and controls are in place for internal review and authorisation of the information provided (paragraph 11; note to paragraph 11 identifies Lloyd’s General Representative in Australia as responsible for ensuring policies and procedures are in place).
• Ensure that information is received by APRA or its agent no later than the due date specified (paragraph 17).
• Follow the field-level rules and definitions in LOLRF 800.1: mandatory/optional/T fields, date formats (DDMMYYYY), numeric/alpha formats, currency conversion rules, and the specific treatment of premium fields, endorsements and cancellations (the Record Layouts and field definitions).
• Report each endorsement that changes exposure with separate records showing before and after exposures (Appendix B and record guidance).

Rights and discretions of APRA:

• APRA may change reporting periods, require more or less frequent submissions, or base reporting periods on a Lloyd’s underwriter’s own accounting financial year for part of the information required, by written notice having regard to Lloyd’s circumstances and supervisory needs (paragraph 7).
• APRA may determine alternative IT or delivery requirements and alternative recipients/addresses for submissions (paragraph 10).
• APRA may determine who may authorise information provided by Lloyd’s, specifying persons or positions who may authorise submissions (paragraph 13).
• APRA may make minor variations to LOLRF 800.1, including correcting technical or programming errors, varying occupation codes, or varying table specifications, and must notify Lloyd’s in writing of such changes (paragraphs 14-15).
• APRA conducts validation checks and expects reconciliation of earned premium to be within 5% of the aggregate figures; APRA expects explanations and potentially additional information where discrepancies exceed that tolerance (Appendix A).

Operational duties concerning security and authorisation:

• Fujitsu Australia (agent of APRA) will provide Lloyd’s with a customer identification number and manage password allocation; Lloyd’s must apply for and use a password to create an encrypted session for transmission (paragraph 12).
• APRA may determine alternative authorisation arrangements and alternative persons permitted to authorise submissions (paragraph 13).

Data specifics and accuracy:

• Lloyd’s must ensure data fields marked as mandatory are provided, and fields marked with an asterisk form a unique key for each reporting period (Policy Data Specifications and field definitions).
• Currency conversion and premium treatment rules must be applied as specified (e.g., exclude FSL, GST & SD; convert to A$ using end of processing month exchange rates; gross annualised premium is not gross written premium but a 12-month rate based on rating factors) (field definitions for 15a, 15b, 16).

Notice and communication duties:

• APRA must notify Lloyd’s in writing of minor variations made under paragraph 14 (paragraph 15).

Absence of express statutory penalties in the Standard:

• The Reporting Standard itself does not specify explicit penalties or enforcement measures in the text provided. The Standard is made under s 13 of the Financial Sector (Collection of Data) Act 2001 (paragraph 1), but the Standard does not include its own penalty clauses. APRA’s other powers and enforcement mechanisms under the enabling legislation are not set out in this Reporting Standard text. Where APRA seeks explanations or additional information in the course of validation, it expects Lloyd’s to provide supporting material (Appendix A).

The Reporting Standard, as published, does not contain express pecuniary penalties, infringement notices or criminal sanctions within its text. The document is issued as a Reporting Standard under the authority of s 13 of the Financial Sector (Collection of Data) Act 2001 (paragraph 1), but the Standard itself limits its enforcement language to operational powers and validation expectations.

Enforcement and compliance mechanisms evident in the text:

• APRA’s discretionary powers to alter reporting requirements, methods of submission, and authorised signatories are tools that can compel action; APRA may issue written notices changing reporting periods or requiring alternative submission arrangements (paragraphs 7 and 10). The capacity to re-specify reporting obligations is an administrative lever to manage compliance.
• APRA validates submissions and sets a reconciliation tolerance: Appendix A states earned premium reported by Lloyd’s is “expected to reconcile to within 5%” of aggregate figures; APRA “will expect Lloyd’s to explain the source of any greater discrepancy” and “will expect that Lloyd’s needs to demonstrate the reason for a discrepancy” and may request additional information (Appendix A). These validation processes create an ongoing supervisory dialogue and information rights for APRA.
• APRA may determine alternative arrangements for submission and authorisation (paragraphs 10 and 13). Those determinations can extend or constrain who can transmit or authorise data and where it is delivered.
• Operational controls such as secure login, password provisioning and encryption (paragraph 12) support integrity of submissions; failure to use authorised credentials could lead to rejection of the submission or requirements to re-submit.

What the Standard does not specify (as per the text):

• It does not specify fines, sanctions, civil penalties, or criminal offences for non-compliance within the Standard itself. The reader should not infer particular enforcement penalties from the Reporting Standard text alone.
• The Standard does not set out processes for dispute, administrative review, or appeal regarding APRA determinations within this document.

How enforcement would be derived in practice (source-limited statement):

• Because the Standard is made under s 13 of the Financial Sector (Collection of Data) Act 2001 (paragraph 1), enforcement options outside this instrument may exist in the enabling statute or other APRA powers; however, those provisions are not included in the text provided and therefore are not described here. The Standard relies mainly on administrative instruments: notices, determinations, validations and demands for explanation and additional information (paragraphs 7, 10, 12-15; Appendix A).

Practical consequence: The supervisory and validation regime (particularly the 5% reconciliation expectation and the ability of APRA to require alternative submission methods or extra information) creates compliance risk for Lloyd’s; operational failure to meet format, timeliness, reconciliation or authorisation requirements will trigger APRA validation follow-up according to the procedures set out in the Standard (paragraphs 8, 9, 11, 12; Appendix A). The Standard requires that Lloyd’s ensure data receipt by APRA or its agent by the due date (paragraph 17), giving APRA a basis to treat late or non-delivery as non-compliance under its supervisory regime.

The Reporting Standard is explicitly framed as an instrument under a primary data-collection statute and cross-references multiple other instruments and standards.

Primary statutory basis: The Standard is made under section 13 of the Financial Sector (Collection of Data) Act 2001 (paragraph 1). The text does not reproduce the enabling Act’s enforcement or sanctioning provisions; those remain in the Act itself, which is outside the text provided.

APRA institutional context: APRA is identified as the Australian Prudential Regulation Authority established under the Australian Prudential Regulation Authority Act 1998 (definition in paragraph 16). The Standard also references “agent of APRA” meaning a person appointed under s 47 of the APRA Act 1998 (definition in paragraph 16). Fujitsu Australia is explicitly named as such an agent (paragraphs 9 and 12).

Insurance sector context: “Lloyd’s” and “Lloyd’s underwriter” are defined with reference to the Insurance Act 1973 (definitions in paragraph 16). The Standard thus operates in the regulatory architecture that includes the Insurance Act and APRA’s prudential regime.

Accounting and auditing cross-references: Paragraph 18 provides that references to Acts, Regulations, Prudential Standards, Reporting Standards, Australian Accounting Standards or Auditing Standards are references to those instruments “as in force or existing from time to time.” This embeds a pathway for alignment or evolution with accounting and auditing standards that may impact how Lloyd’s compiles or presents financial or premium information for reporting.

Data classification and external standards: For classification of insured organisations, the Standard requires use of the Australian and New Zealand Standard Industrial Classification (ANZSIC) as published in Catalogue Number 1292.0 of the ABS (Policy Data Specifications, field 22). For professional risks, it requires use of APRA occupation codes in Attachment B or Appendix C. This creates an interaction with ABS classification standards and any updates to ANZSIC.

Currency and taxation references: The Record Layouts require currency conversion to Australian dollars using end of processing month exchange rates and specify exclusion of statutory charges such as FSL, GST and stamp duty (FSL, GST & SD) from certain premium fields (field definitions for 15a, 15b, 16). That interacts operationally with tax laws and accounting practices affecting premium treatment.

Information handling and publication: The Standard states APRA will use the collected information for prudential supervision and publication, including publication in the National Claims and Policies Database (paragraph 2). Field 7 (Policy Number) is explicitly marked as used only for APRA cross-referencing and “will not be published except in any individual data reports prepared for the insurer concerned.” This creates an interaction between APRA’s internal confidentiality practices and its external publication obligations.

Operational agent contract relationships: Fujitsu Australia as APRA’s agent is named and given specific functions (paragraphs 9 and 12). Any contractual or privacy obligations between APRA and Fujitsu are outside the Standard text, but the Standard presumes an existing agent relationship under APRA Act mechanisms.

Adaptation and variation: APRA’s power to make determinations and minor variations (paragraphs 7, 10, 14-15) means the Reporting Standard is designed to evolve without legislative amendment, interacting with administrative law principles on procedural fairness and reasonable exercise of discretion, although those broader legal principles are not addressed in the Standard text.

Limitations in source: The Standard itself does not contain cross-referenced enforcement provisions from the enabling Act, data privacy statutes, or detailed FOI/publishing protocols; therefore any interaction with privacy laws, secrecy provisions, or APRA’s enforcement regime must be checked against the underlying statutes and APRA policy documents beyond this Reporting Standard.

The Reporting Standard text contains internal markers and effective dates which indicate timeline aspects and mechanisms for amendment and variation. The document itself does not provide a formal change log with dates of prior amendments; instead it contains operative commencement and cross-references evidencing historical or standing requirements.

Key dates and standing changes in the text:

• The Standard is made under s 13 of the Financial Sector (Collection of Data) Act 2001 (paragraph 1). No earlier versions are included in the text.
• Commencement: The Standard applies for reporting periods ending on or after 31 December 2021 (paragraph 4). That is the operative commencement point for this instrument as printed.
• Reportable policy eligibility: The definition of “reportable policy” is limited to policies entered into on or after 1 January 2003 (paragraph 16). That date is embedded in the definition rather than indicating an amendment to the Standard itself; it signals a policy grandfathering rule.
• Mandatory fields: The Record Layouts include a key stating “M - mandatory field on all records from 1 July 2004.” This indicates an historical requirement in force from that date for certain fields marked M. The Standard reproduces that key; it does not separately chronicle the change but records its existence in the instructions and field definitions.
• APRA variation power: The Standard provides APRA with an explicit process for making “minor variations” to LOLRF 800.1 where APRA forms a view a change is appropriate (paragraph 14). Paragraph 15 requires APRA to notify Lloyd’s in writing if such a variation is made. These paragraphs set out the internal amendment mechanism for the form and supporting specifications.
• APRA determinations: Paragraphs 7 and 10 confer on APRA the ability to change reporting periods and to specify alternative IT or delivery arrangements in writing. These are operational amendment mechanisms rather than legislative amendment routes.

No formal prior amendment chronology is printed. The instrument embeds mechanisms for administrative amendments without recourse to formal reissue:

• Minor, technical and logical corrections, occupation code variations, and table specification changes may be made by APRA and must be notified in writing (paragraphs 14-15).
• APRA may determine a later time for submission for whole or parts of the information or for particular underwriters (paragraph 8).

Implications for users:

• Users should expect the reporting form and Appendix specifications (including occupation codes and table formats) to be subject to change by APRA with written notification; the Standard itself anticipates change and provides internal governance for such changes (paragraphs 10, 14-15).
• Historical obligations (e.g. mandatory fields since 1 July 2004 or the 1 January 2003 inception rule for reportable policies) are preserved in the field notes and definitions. Practitioners should not assume that appearing dates in the form are amendment dates of the Standard as a whole; they may reflect legacy requirements embedded in the instructions and field keys.

If legal certainty on amendment chronology is required, the enabling legislation and APRA’s published Determinations and Notices should be consulted; this Reporting Standard signals where APRA can act administratively but does not provide a complete bill of past amendments.

The text of the Reporting Standard contains no information about litigation or legal challenges to the Standard, APRA determinations, or the reporting form. There are no cases named or cited in the instrument itself. The document is an administrative reporting instrument setting out duties and specifications and does not include a litigation history or references to judicial review or other proceedings.

What the document does record relevant to potential dispute or review:

• APRA’s determinations and minor variations are required to be in writing (paragraphs 7, 10, 14-15). The procedural insistence on written determinations establishes an administrative record which could be relevant in any future review or challenge to APRA’s exercise of discretion.
• Paragraph 18 provides that references to Acts, Regulations, Prudential Standards, Reporting Standards, Australian Accounting Standards or Auditing Standards are to be read as references to those instruments “as in force or existing from time to time.” This adoptive approach may bear on disputes about interpretation over time, because the Reporting Standard explicitly ties itself to the current form of referenced instruments.
• Appendix A sets out validation expectations and anticipates Lloyd’s being required to “explain” discrepancies and “share such additional information with APRA as required.” That clarifies supervisory processes which could be the subject of administrative review in contested cases, although none are recorded in this text.

For a search and analysis of any litigation that might have arisen from this Standard, or judicial consideration of APRA’s exercise of powers under s 13 of the Financial Sector (Collection of Data) Act 2001, the underlying legislation, APRA Notices/Determinations and public case law repositories should be consulted because the Reporting Standard text does not include or reference any litigation.

This Reporting Standard contains many operational details that create traps for the unwary. The “gotchas” below are drawn from the text and point to concrete compliance and data quality risks.

Reporting scope and policy eligibility

• Reportable policy threshold: Only policies entered into on or after 1 January 2003 are reportable (paragraph 16). Submitting older policies may be unnecessary and will not meet the instrument’s definition of reportable policy.
• Exclusions: Reinsurance, marine insurance, domestic householder / owner’s insurance sold with building/contents, and policies solely for events that could not occur in Australia or to Australian residents are excluded (paragraph 16). Misclassification here can lead to over-reporting.

Date, format and uniqueness requirements

• Date format: Dates must be DDMMYYYY with no delimiter (Policy Data Specifications). A single-character slip (e.g., use of ISO date or delimiters) can invalidate records.
• Unique key: Fields marked with an asterisk (e.g., insurer code, class of business, record type, policy basis, month of end of reporting periods, policy number, risk number, product type, effective start date, effective end date , see the asterisked fields in the Policy Data Specifications) “as a combination, must be unique for each reporting period.” Failure to enforce uniqueness will create validation failures.

Premium and currency treatment

• Gross annualised premium vs gross written premium: 15a (Gross Annualised Premium) is explicitly not gross written premium; it is a 12‑monthised rate based on rating factors at the effective start date (field 15a definition). Reporting the gross written premium in this field is a common source of error.
• Exclusion of statutory charges: Premium fields should exclude FSL, GST and stamp duty (FSL, GST & SD) but include commissions and other costs (field definitions for 15a, 15b, 16). Mistaking statutory charges for insurer-borne costs will misstate reported amounts.
• Currency conversion: Report amounts in A$ using end of processing month rates of exchange (field definitions). Inconsistent exchange-rate source or timing will cause reconciliation discrepancies.

Endorsements and exposure records

• Endorsements must be reported as separate records for exposure before and after change and multiple endorsements in a reporting period each require separate records (Appendix B and field instructions under Effective Start/End Dates). Failing to split exposures will lead to inaccurate exposure tracking and reconciliation issues.
• Effective Start/End Date semantics: Field 12 (Effective Start Date) can be equal to or later than Term Inception Date (field 11); where equal to term expiry date this signifies a premium adjustment at expiry (field 12 notes). Misunderstanding these semantics leads to misreporting of earned premium.

Data reconciliation tolerance

• APRA expects reconciliation of earned premium to aggregate figures within 5% (Appendix A). Exceeding this threshold will require Lloyd’s to explain discrepancies and may trigger requests for additional information. Reconciliation differences can stem from exchange-rate choices, omission of facilities premium, or misallocation between earned and written premiums.

Classifications and coding

• Use of ANZSIC 4‑digit codes for certain risks and APRA occupation codes for professional risks (field 22 notes and Appendix C). Mapping client/industry classifications to ANZSIC or to APRA occupation codes can be non-trivial, especially for package policies or complex commercial operations.
• For professional risks, Attachment B codes must be used except code “OMULTI” which has specific facility use only. Misuse of “OMULTI” or incorrect occupation codes will affect data quality.

Security and authorisation

• Credentials and secure session: Use the customer identification number and password provided by Fujitsu to create a secure encrypted session for transmission (paragraph 12). Sharing credentials, using wrong credentials, or mismanaging authorisation could cause rejections. APRA may require alternative authorised persons to sign off (paragraph 13).

Field-level detail and data types

• Field types and widths are prescriptive (e.g., field 7 policy number 30a/n, field 21 limit 12n). Truncation, use of non-conforming characters or exceeding field lengths will cause validation errors.
• Mandatory vs optional fields: Fields marked M are mandatory on all records from 1 July 2004. The “T” designation requires at least one of the premium fields to be populated. Misunderstanding the key could lead to missing mandatory data.

Publication and confidentiality

• Policy number is used only for APRA cross-referencing and “will not be published except in any individual data reports prepared for the insurer concerned” (field 7 explanation). However, publication in aggregate databases still occurs (paragraph 2), so operational confidentiality practices around submission are relevant.

APRA variation and notification

• APRA can change reporting periods and submission requirements in writing (paragraphs 7 and 10). Lloyd’s must monitor APRA notices; failure to act on a variation notice could lead to non-compliance.

Operational integration and costs

• The Standard requires CSV rendered "in accordance with the instructions in LOLRF 800.1" and delivered through the specified web site. Lloyd’s IT systems must be capable of producing the exact CSV format, including date format, field ordering and encoding. Converting multiple internal systems to the standardised layout is a non-trivial project.

Validation and evidence requests

• If reconciliation exceeds 5% APRA “will expect Lloyd’s to explain the source of any greater discrepancy” and “will expect that Lloyd’s needs to demonstrate the reason for a discrepancy” (Appendix A). Be prepared to provide source ledgers, facility premium breakdowns, exchange-rate calculations and endorsement histories.

This section sets out a practical roadmap to meet the Reporting Standard’s requirements as they appear in the text. The steps track obligations in the Standard and identify practical controls and checks.

1. Designate responsibilities and policies

   • Assign accountability to Lloyd’s General Representative in Australia for oversight of reporting arrangements and ensure a written authorisation and data governance policy is in place (paragraph 11, note).
   • Document roles for data extraction, transformation, validation, authorisation and submission. Keep written records of APRA determinations and notifications.

2. Register and obtain credentials

   • Notify Fujitsu Australia (APRA’s agent) of the intended method of delivery and obtain the customer identification number (paragraph 12).
   • Follow the web page process at www.ncpd.apra.gov.au to apply for the password using the customer identification number and ensure secure storage and rotation of credentials as per internal policy (paragraph 12).

3. Map internal data to LOLRF 800.1 template

   • Use the Record Layouts and Field Specifications to construct a data mapping document that links Lloyd’s policy, risk and endorsement data to the required fields (Policy Data Specifications).
   • Ensure unique key combinations for fields marked with an asterisk to meet uniqueness per reporting period.
   • Map ANZSIC 4-digit codes for public/products risks and APRA occupation codes (Appendix C) for professional risks; create a lookup table for repeatable classification decisions.
   • Implement rules for currency conversion to A$ using end-of-processing month rates and for exclusion/inclusion of statutory charges (field definitions for 15a, 15b, 16).

4. Implement formatting and validation rules

   • Implement date format enforcement (DDMMYYYY, no delimiter) and field-type enforcement (alpha/numeric and field widths).
   • Enforce the rule that at least one of fields 15a or 15b is populated for each record (T fields).
   • Ensure fields marked M are always populated (note M - mandatory on all records from 1 July 2004).
   • Implement checks for endorsement reporting: create separate records for exposure segments before and after endorsements, with Effective Start and End Dates properly populated (Appendix B).
   • Ensure coinsurance proportion reflects Lloyd’s overall percentage share to two decimal places (field 23).

5. Build reconciliation and control processes

   • Reconcile field 15b (Gross Earned Premium) to Lloyd’s internal aggregate earned premium and to earned premium submitted elsewhere (e.g., Lloyd’s Security Trust Fund Determination No 1 aggregate) and document any reconciling items.
   • Target reconciliations to be within the 5% tolerance APRA expects; where discrepancies exceed 5% prepare explanatory schedules and source documentation for APRA (Appendix A).
   • Keep audit trails for exchange-rate choices, premium adjustments, endorsement histories and facility premium allocations.

6. Authorisation and submission workflow

   • Follow the password application and use the customer identification number/password for secure session creation; ensure the person(s) authorised to submit are as per APRA determinations and internal policy (paragraphs 12-13).
   • Ensure that authorised persons perform a final validation sign-off (as APRA may require persons or positions to authorise data , paragraph 13).
   • Submit via the specified portal in CSV format following LOLRF 800.1 instructions (paragraph 9).

7. Timing and receipt

   • Default reporting timetable: prepare data for half-year periods ending 30 June and 31 December and submit by no later than four months after the end of the reporting period (paragraphs 6 and 8(a)).
   • Monitor APRA notices in case reporting periods or due dates are changed and be ready to comply within any alternative timeframe APRA specifies (paragraphs 7 and 8(b)). Ensure that data is received by APRA or its agent by the due date (paragraph 17).

8. Respond to APRA validations and requests

   • Maintain readily accessible source records and reconciliations so that, if APRA requests explanations for discrepancies greater than 5% or additional data, you can respond promptly (Appendix A).
   • If APRA issues a determination changing data requirements or the form, implement changes within the timelines specified and ensure written notification is kept on file (paragraphs 10, 14-15).

9. Operational resilience and IT controls

   • Build CSV generation and schema validation tooling, including test harnesses that simulate APRA validation rules where possible (e.g., date checks, numeric ranges, mandatory fields).
   • Implement encryption and secure transport of data as required by the Fujitsu portal; log successful transmissions and receipts.
   • Plan for contingency submission routes: APRA may direct alternative methods or addresses in writing (paragraph 10); ensure your operations can accommodate such determinations.

10. Documentation, audit and continuous improvement

• Keep a versioned record of the CSV layout, mapping rules, conversion tables, classification decisions (ANZSIC and APRA codes), and reconciliation methodologies.
• Maintain evidence of internal review and authorisation per paragraph 11; these will be the primary controls APRA expects to see in validation.
• Subscribe to APRA notices and updates to LOLRF 800.1 and Appendix C and implement notified changes; APRA must notify in writing when making minor variations (paragraph 15).

Operational checklist summary (to be ticked for each submission):

• [ ] Policies selected meet “reportable policy” definition (post 1 Jan 2003, correct class).
• [ ] All mandatory (M) fields populated; at least one T field populated.
• [ ] Dates formatted DDMMYYYY with no delimiters.
• [ ] Currency converted to A$ using end-of-processing month rates; statutory charges treated per instructions.
• [ ] Endorsements and cancellations split into exposure records with correct Effective Start/End Dates.
• [ ] ANZSIC/occupation codes assigned and documented.
• [ ] Reconciliation prepared to demonstrate earned premium within 5% tolerance.
• [ ] CSV validated against field types and field lengths.
• [ ] Submission authorised by specified person(s) and transmitted using customer ID/password.
• [ ] Receipt logged and retained.

Following the above steps will address the operational and data-quality obligations stated in the Reporting Standard and place Lloyd’s in position to respond to APRA validation queries and to comply with any APRA determinations about reporting periods, formats or authorised signatories (paragraphs 7, 10, 12-15; Appendix A).