Loan processing for HECS HELP, FEE HELP and VSL loans

As data is submitted, TCSI will undertake a range of real-time validation (RTV) checks. RTVs check that any new data reported by a provider is internally consistent with data that the provider has previously reported. For example, if a provider reported that a student is an international student and then subsequently tries to report a loan for that student, the system will recognise the data inconsistency; will prevent the new data from being stored; and will immediately return an error message to help the provider resolve the source of the error.

StEME will create a loan as soon as the provider successfully reports[1] a unit enrolment packet where:

• there is enough information on the linked student record to uniquely identify the student and either verify or issue a Commonwealth Higher Education Student Support Number (CHESSN) for the student
• the student status code (E490) indicates that the student will access a HECS-HELP, FEE-HELP or VSL loan to pay their student contributions or tuition fees for the unit of study, and
• the loan amount (E558) is greater than 0.

This means that a provider must successfully report E490, E558 and all the minimum data elements for a unit enrolment packet plus sufficient identifying data on the linked student record for a CHESSN to be generated before StEME will create a loan.

[1] Successfully reports means to report data that passes all the applicable RTV checks and is then stored in the TCSI database.

Once StEME has created a loan record, it will conduct a serviceability check, which works out whether the loan amount (E558) can be covered by the student’s HELP balance. This involves putting all the loans a student has at all providers in the order in which the loans will consume the student’s HELP balance. Loans with an earlier census date consume balance before loans with a later census date. Where there are loans with the same census date, they will be processed in the order they were created or last amended.

Once the loans are put in this ‘order of precedence’, StEME sequentially checks each loan against the student’s HELP balance and sets a ‘loan status’ (see the table below) for each loan based on whether the student has balance to either fully or partially service the loan.

TCSI enables providers to report loan related data as soon as a student has indicated that they want a loan for a unit of study that they are enrolled in. Early reporting is encouraged as this will give providers early feedback on whether loans will be serviceable. However, providers have until 14 days after the census date to report loan data, which means that StEME won’t have a complete picture of all loans for a census date until 15 days after that census date.

For this reason, loans will have a ‘pending’ loan status until 14 days after the census date. Although the loan status does not change on the census date, the student’s HELP balance will be adjusted by the value of the loan on the census date. HECS-HELP and FEE-HELP loans will receive a non-pending status 15 days after the census date. VSL loans move to a non-pending status after other checks in Stage 4.

For VET Student Loans (VSL), the loan status will not automatically change from a pending to a non-pending status 15 days after the census date. All ‘pending’ VSL loans are subject to further eligibility checks such as VSL course loan limit checks and the outcome of these checks is indicated in the loan status once those checks are completed.

Under the reporting requirements, providers should have reported all data for loans within 14 days after the census date. This may not always be possible, for example, the student’s Tax File Number (TFN) may not be available if a student is accessing a loan based on an ATO certificate of application for a TFN. Messages will be placed on the provider’s notification table where TCSI identifies that data has not been reported by the reporting deadline. See Scheduled Validations (TBC).

A loan will be sent to the ATO as soon as the:

• provider successfully reports all the data that is relevant to a student’s eligibility for a loan (such as the citizen resident code) and the data needed to send a loan to the ATO (for example, TFN), and
• loan status is ‘accepted’, ‘adjusted’ or ‘VET approved’.

The following loan statuses will apply as loans are sent to and received by the ATO:

If a provider successfully reports a change to a loan type by amending the student status code (E490), the loan amount (E558) or the census date (E489) on the unit enrolment record, StEME will re-assess the serviceability of that loan and all loans with a lower precedence. The loan status will be updated if needed and, if the original loan record was sent to the ATO, StEME will send any necessary amendments to the ATO.

Although providers can report a loan up to 14 days after the census date, payment arrangements for student contributions and tuition fees are to be final by the census date. This means that once a loan status has been set to:

• ‘adjusted’, StEME will not increase the loan amount due to changes to other loans held by the student but it will reduce the loan amount or reject the loan if needed to stop a student from exceeding their HELP limit
• ‘rejected’, StEME cannot un-reject the loan due to changes to other loans held by the student.

If a loan is found to be unserviceable after the loan has been sent to the ATO, the ATO will be advised and the loan will have a loan status of ‘invalidated’. If the loan is found to be unserviceable before the loan was sent to the ATO, it have a loan status of ‘rejected’ and the original loan will never be sent to the ATO.

If a loan is found to be partially unserviceable after the loan has been sent to the ATO, the original loan will be ‘invalidated’ and StEME will create a new loan with the adjusted loan amount to send to the ATO, with a final status of ‘adjusted committed’.

StEME will delete a loan record if a provider successfully changes the student status code (E490) to a non-loan code, sets the loan amount (E558) to 0 or deletes the linked unit enrolment record. When a loan is deleted, StEME will re‑assess the serviceability of all pending loans with a lower precedence.

If the deletion of a loan occurs after the loan has been sent to the ATO, the ATO will be advised and the loan will have a loan status of ‘reversed’. If the loan is deleted before the loan was sent to the ATO, it will retain a loan status of ‘deleted’ and will never be sent to the ATO.

If a provider successfully reports a value for the remission reason code (E446), StEME will re-assess the serviceability of pending loans with a lower precedence.

If the remission is received after the loan has been sent to the ATO, the ATO will be advised and the loan will have a loan status of ‘remitted’. If the remission is received before the loan was transmitted to the ATO, it will have a loan status of ‘remission’ and will never be sent to the ATO.

Loan repayment data from the ATO will be available to StEME on a monthly basis. StEME will reassess the serviceability of all loans with a census date on or after the day that repayment data is received. This could lead to loans with a status of ‘rejection pending’ being upgraded to ‘adjustment pending’ or ‘acceptance pending’ or loans with a status of ‘adjustment pending’ being upgraded to ‘acceptance pending’.

A message will be placed on the provider’s notification table when there is a change to a loan that the provider needs to know about, including when the:

• loan is assessed as ‘adjustment pending’ or ‘rejection pending’
• status of the loan is downgraded, for example, its status changes from ‘acceptance pending’ to ‘adjustment pending’ or ‘committed’ to ‘invalidated’, etc.
• status of the loan is upgraded, for example, its status changes from ‘rejection pending’ to ‘adjustment pending’, or from ‘adjustment pending’ to ‘acceptance pending’, etc.

If a provider retrieves the status of a loan, any notifications about the loan status will be deleted from the provider’s notification table.

A message will not be placed in the provider’s notification table for a ‘business as usual’ progression of a loan or for loan changes initiated by the provider. For instance, messages are not created when a loan:

• is created and its status is set to ‘accepted’ or ‘acceptance pending’
• is deleted as the result of the provider deleting the unit enrolment, amending the loan amount (E558) to nil, or the student status code (E490) to a non-loan code
• is remitted
• moves through the loan lifecycle without being upgraded or downgraded as the result of StEME reassessing the serviceability, for example, the loan status changes from ‘acceptance pending’ to ‘accepted’ to ‘committed’, or from ‘rejection pending’ to ‘rejected’, etc.

For providers using APIs, the loan statuses for each of their loans can be obtained through the Loans API endpoint. For providers using TCSI Data Entry, loan statuses can be obtained through the unit enrolment record. TCSI Analytics will also host a report view of loans, which can be downloaded.

The sooner providers report student records and unit enrolments records, the sooner StEME can check student loans for serviceability and the sooner providers will have access to information about whether the loan will be payable by the Government or whether the provider will need to seek upfront payment from a student.

Providers have until 14 days after the census date to report loan data but delayed reporting is not recommended where it is avoidable. Delays in the reporting of data reduces the amount of time providers will have to identify students who will not be able to finance their study with a HELP or VSL loan, especially students who may be concurrently enrolled at more than one provider.

Administrative errors that result in the reporting or amendment of loan data more than 14 days after the census data can have an adverse impact on students and other providers the student may be enrolled with. Providers should note that legislative sanctions are available and may be used where providers frequently report and amend loans data after the reporting deadline.

The following examples show how the loan status changes through the loan life cycle depending on the serviceability of the loan and loan updates sent by providers.

Example 1: Loan is reported before the census date, is fully serviceable through the loan life cycle

Example 2: Loan is reported before the census date and is partially serviceable through the loan life cycle

Example 3: Loan is reported before the census date and is unserviceable and remained so up to the reporting deadline

Example 4: Loan started as unserviceable but the deletion of other loans before the reporting deadline made the loan serviceable

Example 5: Loan started as fully serviceable but the reporting of other loans before the reporting deadline made the loan unserviceable

Example 6: Loan started as fully serviceable but the reporting of other loans after the loan was sent to the ATO made the loan unserviceable

Example 7: Loan was fully serviceable but was deleted before the loan was sent to the ATO

Example 8: Loan was fully serviceable but was deleted after the loan was sent to the ATO

Example 9: Loan was fully serviceable but was remitted before the loan was sent to the ATO

Example 10: Loan was fully serviceable but was remitted after the loan was sent to the ATO