EBA RT1 SEPA Credit Transfer INST

Used for obtaining JWT token based on clientid and secretkey.

Used for revoking JWT token based on clientid and secretkey.

The Current Position request allows the Participant to inquire about its real time liquidity position in the SCT Inst. Upon receiving this Request, the SCT Inst will inquire the real time Position of the inquiring Participant and returns the value of the timestamp of the reading. The result of the inquiry done for a Participant that is not part of a Liquidity Pool will always be a positive value. If the Participant belongs to a Liquidity Pool, it is possible that the Current Position is a negative value. The SCT Inst will always verify if the Participant is part of a Liquidity Pool, if this the case the Response will contain the Position of both the Participant and the Position of all Liquidity Pools the Participant is a member of. The response contains the current Position of the Participant. If the Participant is an LP, the system will return the current Position of each LSP for whose liquidity management it is responsible for. In the case that the Participant is a member of one or more Liquidity Pools, the “PoolId” and “PoolPosition” elements contain the Pool identification and the current position of the Pool to which the Participant belongs to. If the Participant is the Owner of one or more Liquidity Pools, the section “OwnedPool” is repeated for each Liquidity Pool that is owns. The “OwnedMember” for each “OwnedPool” lists the members of the Pool and the Position of each member.

The Set Default Position request allows the Participant to set its default position for one day specific of the week, from Monday to Sunday, and for one or more specific LACs of that day. The Participant can set the lower, base, upper and reset to base position values for each LAC specified. Only the values of the specified LACs will be modified. If the Participant is an LSP whose liquidity management is delegated the request is rejected with ErrorCode XA14. If the Participant is an LP, it is allowed to send the SetDefaultPosition Request on behalf of the LSPs whose liquidity management is responsible for. The response contains the EffectiveDate that was calculated by the system as the first occurrence for application of the new default values. This date is the next TARGET relative to the processing date of the request. If the pair Day – LAC in the request is the next one with respect to the current one in the system, the new values are applied only if the API Request is received within the “Liquidity Agenda Grace Time” system parameter that represents the minimum time interval remaining to the end of the current LAC, otherwise the request is rejected. The request must anyway be submitted within the “Routing Grace Time”, the system parameter that represents the time limit before midnight for the Participants to submit requests for updates, otherwise it is rejected with ErrorCode XA08.

The DefaultNetPosition request allows the Participant to retrieve the default values in the SCT Inst for the days in the week, from Monday to Sunday, and all LACs of these days. If the Participant is an LP, it is allowed to send the getDefaultPosition Request regarding the positions of the LSPs on whose behalf such LP is configured to perform liquidity management functions. Only the Owner of a Liquidity Pool is allowed to inquire the default values of a BIC that is a Member of its Pool, in this case it must specify the PoolId and the MemberBic belonging to the Pool for which the request is sent. The response returns the values for each day of week and each LAC for each specific day.

The Set Exception Position Calendar request allows the Participant to set the desired position in the SCT Inst for LACs later than the current LAC of the current Business Date, or for LACs of a Business Date in the future, that is no further than one year from the current date. If the Participant is an LSP whose liquidity management is delegated, the request is rejected with ErrorCode XA14. If the Participant is an LP, it is allowed to send the SetExceptionPositionCalendar Request on behalf of those LSPs whose liquidity management is responsible for. For a LAC of the selected Business Date, the Participant can specify its (or those of the specified LSPBic) lower, base and upper values: they will be exceptionally applied at the occurrence of the BusinessDate and LAC as an exception to the default values of the day of the week associated to the BusinessDate. If the pair BusinessDate – LAC in the request is the next one with respect to the current Business Date-LAC of the system, the new values are applied only if the API Request is received within the “Liquidity Agenda Grace Time” system parameter, that represents the minimum time interval remaining to the end of the current LAC, otherwise the request is rejected. The request must anyway be submitted within the “Routing Grace Time”, the system parameter that represents the time limit before midnight for the Participants to submit requests for updates, otherwise it is rejected with ErrorCode XA08.

The GetExceptionCalendar request allows the Participant to retrieve its own set of values (lower, base,upper and reset to base position) that will be applied for each LAC of a specific day in the future (or for the current business date). It is possible to inquire the calendar up to one year from the current day. If the Participant is an LP, it is allowed to send the GetExceptionPositionCalendar Request for those LSPs whose liquidity management is responsible for. Only the Owner of a Liquidity Pool can inquire the values of a Member belonging to its Pool. The returned values are the ones that will be really applied by the system, if an exception was set for the Business Date, it will be returned in place of the default values. The response contains the values for the request Business Day.

The ReleaseLiquidity request allows the Participant to defund the desired amount from its Position in the SCT Inst to its DCA account in TIPS; the system shall check that the amount to be defunded is less than or equal to the available position of the Participant in the system and, if not, the request shall be rejected. The Participant is allowed to ask for the defunding of the entire amount corresponding to its position. If the Participant belongs to a Pool and the Liquidity Position of the Pool is lesser than the amount to be defunded, the request shall be rejected. If the Participant is an LSP whose liquidity management is delegated, the request is rejected with ErrorCode XA14. If the Participant is an LP, it is allowed to send the ReleaseLiquidity Request on behalf of the LSPs whose liquidity management is responsible for. If the Participant is the Owner of a Pool, it is allowed to use this request to defund the liquidity of another not-suspended BIC that is a Member of the Pool, from the Position of the MemberBic in the system to the DCA account of the MemberBic in TIPS. The response contains the confirmation or rejection of the request. Please, note that the request can be sent to SCT Inst only if the “FREEZE TIPS Exchange Liquidity” command has not been issued, otherwise the request will be rejected with ErrorCode XA09.

The PreFunding request allows the Participant to request for the transfer of a specified amount from their DCA account in TIPS to the RT1 Technical Account in TIPS, thus to their position in the SCT Inst System. If the Participant is an LSP whose liquidity management is delegated, the request is rejected with ErrorCode XA14. If the Participant is an LP, it is allowed to send the PreFunding Request on behalf of the LSPs whose liquidity management is responsible for. If the Participant is the Owner of a Pool, it is allowed to use this functionality to move the liquidity of a not-suspended BIC that is Member of the Pool, from the DCA account of the MemberBic in TIPS to the Position of the MemberBic in the system. After receiving the Request for Prefunding by the Participant, the system sends a camt.050 message to TIPS with the instructions to make the funds available, and afterwards, when the system receives the camt.054 message from TIPS, it increases the position of the Participant with the required amount. The requests for pre-funding are sent from the SCT Inst to TIPS and are asynchronous meaning that the application of the funds to the position of the Participant will be subject to a time delay. The positive response is a confirmation that the request has been sent to TIPS for processing. Please, note that the request can be sent to SCT Inst only only if the “FREEZE TIPS Exchange Liquidity” command has not been issued, otherwise the request will be rejected with ErrorCode XA09.

The LiquidityTransfer request allows the Owner of the Liquidity Pool to request for the transfer of a specific amount from one Participant to another Participant, both not-suspended and belonging to the same Pool. The transfer of funds has an immediate effect meaning positions have already been adjusted upon receipt of the response to the request. The response contains the confirmation that the funds have been moved between the Participants.

The ListInstructionsFundingDefunding request returns a list of all instructions present in the SCT Inst for a specific BIC and is sorted by Date. It is possible to fill one or more fields as filtering criteria: in that case, the API Response returns the full set of rows corresponding to the filter criteria. If the Participant is an LP, it is allowed to inquire the instructions of the LSPs whose liquidity management is responsible for. If the Participant is the Owner of a Pool, it is allowed to inquire the instructions of another BIC that is a Member of the Pool that it owns. The configuration of LSP and Pools taken into account for checks by the system is the one present at the moment in which the API Request is received: no restriction is applied to old stored instructions for which a different configuration was active. If all the checks pass, but the system does not find any instruction related to the filtering criteria of the Request, the reason Code 204 – No Record Found is returned. The resulting list shall contain a maximum of 1000 rows satisfying the criteria, in the case that the result has more than 1000 matching instructions, the response will contain an offset. By resubmitting the same request with a different offset value the Participant can retrieve all matching instructions

The ListInstructionsFundingDefunding request returns a list of all instructions present in the SCT Inst for a specific BIC and is sorted by Date. It is possible to fill one or more fields as filtering criteria: in that case, the API Response returns the full set of rows corresponding to the filter criteria. If the Participant is an LP, it is allowed to inquire the instructions of the LSPs whose liquidity management is responsible for. If the Participant is the Owner of a Pool, it is allowed to inquire the instructions of another BIC that is a Member of the Pool that it owns. The configuration of LSP and Pools taken into account for checks by the system is the one present at the moment in which the API Request is received: no restriction is applied to old stored instructions for which a different configuration was active. If all the checks pass, but the system does not find any instruction related to the filtering criteria of the Request, the reason Code 204 – No Record Found is returned. The resulting list shall contain a maximum of 1000 rows satisfying the criteria, in the case that the result has more than 1000 matching instructions, the response will contain an offset. By resubmitting the same request with a different offset value the Participant can retrieve all matching instructions

A Participant can inquire the detail of any single instruction related to an adjustment exchanged with TIPS

A Participant can inquire the list of the relevant messages exchanged with TIPS

The MessageDetails request allows the Participant to retrieve the details of a specific message, exchanged with TIPS

This API is available for Liquidity Provider Participants only. This API allows a Liquidity Provider to request the generation of an outbound LTO message for a specific Beneficairy PSP. The relevant camt.050 message is then forwarded to TIPS

A Participant can request the generation of a Payment Status Query Message to be sent to TIPS in order to retrieve the satus of a previously exchanged pacs.008 or pacs.004 message

This API is available for Liquidity Provider Participants only. This API allows a Liquidity Provider to request the generation of a get Account balance message in order to inquiry its DCA account. The relevant camt.003 message is then forwarded to TIPS

The List Beneficiary request allows the Liquidity Provider to retrieve all Beneficiaries configured in the System for its BIC

A Liquidity Provider can manage its beneficiary BICs

The getParticipants request returns a list of all Participants present in the SCT Inst and is sorted by BIC and InitValidityDate. It is possible to fill one or more fields as filtering criteria: in that case, the API Response returns the full set of rows corresponding to the filter criteria.

The participantDetails request allows a Participant to retrieve the details of a specified Participant in the SCT Inst. If the inquiring Participant asks for their own details they are allowed to download the complete set of parameters, otherwise they can see only a subset of the whole set. The response contains a list of the parameter modifications associated to the BIC, containing the old configurations, the current one, and the new planned one if it has been already authorized.

The UpdateParticipant request allows a Participant to update its configuration in the SCT Inst. The Participant can fill only the new values of the configuration elements that have to be changed; elements that are not present in the request are not involved in the change and the system will keep the existing values for them. If the Participant is an LSP, it is allowed to submit a request for change of its Liquidity Management. If the Participant is an LP, it is not allowed to change its own Liquidity Management parameter. The Products section is optional, but if present the Product must be different from the default value “INST”, which is mandatory for all the Participants of the SCT Inst. The positive response contains the ReferenceId of the take in charge request for change by the system, but the effective modification of the master data has not been executed yet. Application will only take place after final authorization of the Dual Control by EBA CLEARING. The ReferenceId can be subsequently used in the CommandStatusInquiry request to get the status of the submitted command, see ref. 1.1. The request must anyway be submitted within the “Routing Grace Time”, the system parameter that represents the time limit before midnight for the Participants to submit requests for updates, otherwise it is rejected with ErrorCode XA08. The parameters provided in this API are classified as Critical or non-critical, see ref. 9.20 Depending on the nature of the parameter, Critical or Not Critical, checks performed on the effective date change: For Critical parameter: • if the command is issued on between Monday W1, and Tuesday the first effective date will be the Tuesday of the W3 week • if the command is issued between Tuesday Wednesday and Sunday W1 the first effective date will be the Tuesday of the W4 For Not Critical parameter: • the effective date must be grater than the current business date, , with respect to the End Validity Date configured for the Participant.

The ListAPs request allows the Participant to retrieve the list of all APs in the SCT Inst sorted by BIC, DPBIC, and Status. It is possible to fill one or more fields as filtering criteria: in this case the response returns the full set of rows matching the criteria.

The APDetails request allows the Participant to retrieve the details of an AP. The response contains the details of the specified AP. A request addressed to an AP belonging to the sending participant will be responded with the full set of information available.

The UpdateAP request allows the Participant to update the configuration of a specific AP that the Participant manages in the SCT Inst. The Products section is optional, but if present the Product must not contain the default value “INST”, which is mandatory for all the APs of the system. The positive response contains the ReferenceId of the take in charge request for change by the system, but the effective modification of the master data has not been executed yet. Application will only take place after final authorization of the Dual Control by EBA CLEARING. The ReferenceId can be subsequently used in the CommandStatusInquiry request to get the status of the submitted command, see ref. 1.1. The negative response contains the Code 204 if no record satisfying the set criteria is found. The request must anyway be submitted within the “Routing Grace Time”, the system parameter that represents the time limit before midnight for the Participants to submit requests for updates, otherwise it is rejected with ErrorCode XA08

The ChangeStatusAP request allows the Participant to change the status of an AP that it manages in the SCT Inst, to: - r-only (“RON”) if it was a valid AP (enabled) or to - Disabled (“DIS”) if it was an r-only AP. The positive response contains the ReferenceId of the take in charge request for change by the system, but the effective modification of the master data has not been executed yet. Application will only take place after final authorization of the Dual Control by EBA CLEARING. The ReferenceId can be subsequently used in the CommandStatusInquiry request to get the status of the submitted command, see ref. 1.1. The negative response contains the Code 204 if no record satisfying the set criteria is found. The request must anyway be submitted within the “Routing Grace Time”, the system parameter that represents the time limit before midnight for the Participants to submit requests for updates, otherwise it is rejected with ErrorCode XA08.

The InsertAP request allows the Participant to add a new AP that it wants to manage in the SCT Inst. The Product is optional in both request and response; the system automatically associates the default Product “INST” to each AP that is added by the Participant. The positive response contains the ReferenceId of the take in charge request for change by the system, but the effective modification of the master data has not been executed yet. Application will only take place after final authorization of the Dual Control by EBA CLEARING. The ReferenceId can be subsequently used in the CommandStatusInquiry request to get the status of the submitted command, see ref. 1.1. The request must anyway be submitted within the “Routing Grace Time”, the system parameter that represents the time limit before midnight for the Participants to submit requests for updates, otherwise it is rejected with ErrorCode XA08.

The Communication of unavailability request allows the Participant to communicate his temporary unavailability. Using this API, RT1 user can inform the system about the unavailability or the resumption of availability. It is possible to indicate the time of those events and to send a new message to update a previous one (e.g. to indicate that the expected duration of the unavailability will be shorter / longer). Optionally, RT1 users can indicate whether all the other RT1 users shall be informed. In such a case, all RT1 users can access to the information.

The Inquiry unavailability request allows the RT1 user to inquiry the unavailability of the participants, due to what communicated with the function Communication of Unavailability.

The List Participant Operation request allows the Participant to retrieve the list of a specific operations based on a search filter. The response returns the requested details or Code 204 if no record satisfying the criteria is found.

The Participant Operation Details request allows the Participant to retrieve the details of specific provisioning operations based on a search filter. The response returns the requested details or Code 204 if no record satisfying the criteria is found.

The Reject Participant Operation allows the Participant to reject a specific change operation submitted and not yet authorized. (See 9.11) The response contains the confirmation or rejection of the request, Code 204 is returned if no record is found satisfying the selected criteria.

The system shall use the AcceptanceDateTimeFrom timestamp as the start point of the search and the same UTC format as the AT-50 contained in the instant payment pacs.008. The Participant has the option to specify the AcceptanceDateTimeFrom up to the level of milliseconds to fine-tune the timeframe of the search.

The PaymentDetails request allows the Participant to retrieve the details of a specific Payment Transaction that it sent to or received from the SCT Inst. The response returns the requested details.

The ListTransactions request allows the Participant to retrieve a list of R-messages (pacs.004, pacs.002, pacs.028, camt.056 and camt.029) send to or received from the SCT Inst. The Participant has the option to use filtering criteria to reduce the number of transactions in the response. In the case that the result has more than 1000 matching transactions, the response will contain an offset. By resubmitting the same request with a different offset value the Participant can retrieve all matching transactions. The response will return a list of all R-messages, matching the criteria of the request that is sorted by TransactionId, ProcessingDate, ReceptionTime, InstructingBic, InstructedBic and TransactionStatus. The resulting list shall contain a maximum of 1000 R-messages. The transactions rejected due to acceptance-date-time (AT-50) already expired when received by RT1 System are not displayed (In case the pacs.008 cannot be delivered to the BB, because it is not reacheable (AB07) or when the pacs.008 arrive in the CS already overdue (and it is consequently not delivered to the BB and rejected to the OB for timeout - AB06), the transaction will not be visible in the PWS and API by the Beneficiary Bank but will be notified in the RSF file. In case the transaction is delivered to the BB and then goes in timeout (TM01 for BB and AB06 for OB), it is then visible via PWS and API to both OB and BB.)

The TransactionDetails request allows the Participant the retrieve the details of a specific R-message, Payment Status Report or Investigation sent to or received by the SCT Inst. The response contains the R-message, Payment Status Report or Investigation details.

The List Files request allows the Participant to retrieve a list of files sent by the SCT Inst to the Participant. The Participant has the option to use filtering criteria to reduce the number of files in the response. The response will return a list of all files that match the criteria of the request and is sorted by DateFrom, TimeFrom, FileType, FilreRef and FileStatus. The resulting list shall contain a maximum of 1000 files, or Code 204 if no record satisfying the set criteria is found. The system shall use the AcceptanceDateTimeFrom timestamp as the start point of the search. The Participant has the option to specify the DateTimeFrom up to the level of seconds to fine-tune the timeframe of the search. Milliseconds and nanoseconds are not supported by the API.

The FileDetails request allows the Participant to retrieve the details of a file received from the SCT Inst. The response returns the details of the file specified.

The ListCommandsStatus request allows the Participant to retrieve a list of all commands issued by its staff via GUI or via API that fall under Dual Control. It is possible to filter the result to a particular command type or requestor. The SCT Inst uses the RequestDateTime as the starting point of the response data which is sorted by SubmissionDate, RequestStatus and CommandType. The Response is limited by a maximum of 1000 commands.

The Command Status Details request allows the Participant to view the details of a specific command that it submitted to the system. The response contains the details of the command submitted by the Participant, or Code 204 if no record is found satisfying the selected criteria

The Command Delete request allows the Participant to delete a specific command that was submitted to the system and that has not been authorized yet by EBA CLEARING staff. The response contains the confirmation or rejection of the request, Code 204 is returned if no record is found satisfying the selected criteria.

The ListAlerts Request allows the Participant to get all the alerts that were generated by the SCT Inst for the Participant. The Participant can use filtering criteria to restrict the number of alerts listed. If the Participant is an LP, in the full set of the returned Alerts there are also the ones regarding the liquidity change of the positions of the LSPs on whose behalf such LP is configured to perform liquidity management functions. The response contains the list of all Alerts that match the criteria and is sorted by AlertDate. The response contains a maximum of 1000 Alerts

The GetInterestAmount request returns the Interest Amount calculated by the System for each day of the required month. Retrieved data shall be sorted by date. A Liquidity Provider is allowed to perform inquiries on interests calculated for any of its LSP. An Owner of a Liquidity Pool is allowed to perform inquiries on interests calculated for its Branch Pool(s). The Monthly interest information (with Daily Accrual Details) will be available for the selected month only after the Interest Calculation Process has run, otherwise no data will be provided for the month requested, and the following error XA19 will be returned to the API User: “The Interest Calculation has not been calculated for the requested month”.

The UpdateAP request allows the Participant to update the configuration of a specific AP that the Participant manages in the SCT Inst. The Products section is optional, but if present the Product must not contain the default value “INST”, which is mandatory for all the APs of the system. The positive response contains the ReferenceId of the take in charge request for change by the system, but the effective modification of the master data has not been executed yet. Application will only take place after final authorization of the Dual Control by EBA CLEARING. The ReferenceId can be subsequently used in the CommandStatusInquiry request to get the status of the submitted command, see ref. 1.1. The negative response contains the Code 204 if no record satisfying the set criteria is found. The request must anyway be submitted within the “Routing Grace Time”, the system parameter that represents the time limit before midnight for the Participants to submit requests for updates, otherwise it is rejected with ErrorCode XA08

The APDetails request allows the Participant to retrieve the details of an AP. The response contains the details of the specified AP. A request addressed to an AP belonging to the sending participant will be responded with the full set of information available.

The APDetails request allows the Participant to retrieve the details of an AP. The response contains the details of the specified AP. A request addressed to an AP belonging to the sending participant will be responded with the full set of information available.