ato logo
Search Suggestion:

Versioning scenarios

An overview of versioning scenarios.

Last updated 15 January 2018

VS5.1 Both Fund A and Fund B are v1 and v2 compliant – all messages sent in v2

Scenario: Both Fund A and Fund B are v1 and v2 compliant – all messages sent in v2 Flow chart between Fund A and B with Gateways A and B and FVS in between. Fund A connects to Gateway A through IRR V2 and RTOR V2. Only RTR V2 flows from Gateway A to Fund A. Fund A and Gateway A both connect to and receive information from FVS. Gateway A connects to Gateway B through IRR V2 and RTOR V2. RTR V2 flows from Gateway B to Gateway A. Gateway B connects to Fund B through IRR V2 and RTOR V2. Fund B connects back to Gateway B through RTR V2. Fund B and Gateway B both connect to and receive information from FVS.

Notes:

  • FVS will be called either by the Funds or the Gateways, depending on the agreement between the Fund and Gateway. The obligation is on the sending solution to send in the correct version.
  • Fund B would use the FVS to determine which version to send the RTR in, because IRR and RTR are not linked
  • Fund A would use the Service Value in the RTR to determine what value to send the RTOR in.

VS5.2 – Incorrect Scenario Both funds v2 compliant, but RTR sent in v1

Scenario: Incorrect Scenario Both funds v2 compliant, but RTR sent in v1 Flow chart between Fund A and B with Gateways A and B and FVS in between. Fund A connects to Gateway A through IRR V2 and RTOR V1. Only RTR V1 flows from Gateway A to Fund A. Fund A and Gateway A both connect to and receive information from FVS. Gateway A connects to Gateway B through IRR V2 and RTOR V1. RTR V1 flows from Gateway B to Gateway A. Gateway B connects to Fund B through IRR V1 and RTOR V1. Fund B connects back to Gateway B through RTR V1. Fund B and Gateway B both connect to and receive information from FVS.

Notes:

  • RTR should have been sent in v2 because it is the highest/latest version that is available to both the sender and receiver.
  • Trustee decision to accept or reject (If it is sent in v1 in error, trustee would most likely process providing it is before v1 is closed out). Any error handling to be done out of band – no new error or warning message will be created.
  • The RTOR is sent in v1 because Fund A would use the Service Value in the RTR to determine what version to send the RTOR in.

VS5.3 Fund A v1 and Fund B v2 – fund A moves to v2 post sending IRR

 Scenario: Fund A v1 and Fund B v2 – fund A moves to v2 post sending IRR Flow chart between Fund A and B with Gateways A and B and FVS in between. Fund A connects to Gateway A through IRR V1 and RTOR V2. Only RTR V2 flows from Gateway A to Fund A. Fund A and Gateway A both connect to and receive information from FVS. Gateway A connects to Gateway B through IRR V1 and RTOR V2. RTR V2 flows from Gateway B to Gateway A. Gateway B connects to Fund B through IRR V1 and RTOR V2. Fund B connects back to Gateway B through RTR V2. Fund B and Gateway B both connect to and receive information from FVS.

Notes:

  • RTR is sent in V2 because it is sent in the highest version that both Fund A and Fund B can accept.
  • RTR does not need to be in the same version as the IRR because the transactions are not linked.
  • Fund B would use the FVS to determine the version the RTR is sent in
  • Fund A would use the Service Action to determine the version the RTOR is sent in.

VS5.4 Combination of versions: Response message scenarios – linked messages in v1

 Scenario: Combination of versions: Response message scenarios - linked messages in v1 Flow chart between Fund A and B with Gateways A and B. FVS connects to and from Fund A and Gateway A. Fund A connects to Gateway A through IRR V1. Only IRER V1 flows from Gateway A to Fund A. Fund A and Gateway A both connect to and receive information from FVS. Gateway A connects to Gateway B through IRR V1. Only IRER V1 flows from Gateway B to Gateway A. Gateway B connects to Fund B through IRR V1. Fund B connects back to Gateway B through IRER V1.

All the combinations below would result in the same mapping:

  • Fund A V1 & Fund B V1
  • Fund A V2 and Fund B V1
  • Fund A V1 & Fund B V2

Notes:

  • Fund A would use the FVS to determine which version to send the IRR
  • Fund B would use the Service Value in both cases to determine the version the IRER/RTOR is sent in

INTERB1.6 – Fund A v2 and Fund B v1 – incorrect versioning – IRR sent by fund A to fund B in v2

 Scenario: Fund A v2 and Fund B v1 – incorrect versioning – IRR sent by fund A to fund B in v2 Fund A (version 2) connects to Gateway A with IRR V2. Gateway A sends back a Rejection notification to Fund A. Both Fund A and Gateway A connect and receive information from FVS. Fund B (version 1) and Gateway B connect and receive information from FVS.

Notes:

  • IRR should be sent in V1 as Fund B is not ready to accept V2.
  • Gateway would most likely reject the message because that Service Value won’t be registered as a valid Service Value.
  • Depending on the agreement between the Fund and the Gateway, the validation should be done at Gateway A (as part of the sending solution) and rejected by Gateway A. Gateway B should still have validations in place in the event that Gateway A doesn’t reject for some reason.

QC50524