diff --git a/docs/includes/additional/additional20230710-41538-1hep9lq b/docs/includes/additional/additional20230710-41538-1hep9lq
deleted file mode 100644
index 93415bd9..00000000
--- a/docs/includes/additional/additional20230710-41538-1hep9lq
+++ /dev/null
@@ -1,20 +0,0 @@
-<h1 id='additional-standards'>Additional Standards</h1>
-<p>The Consumer Data Standards also incorporate other non-binding standards that are developed to facilitate consultation and feedback or to facilitate voluntary extension of CDR implementations.</p>
-
-<p>These standards fall into three categories:</p>
-
-<ol>
-<li><code>Candidate</code> standards that are non-binding and stable</li>
-<li><code>Draft</code> standards that are non-binding but volatile as they are under development</li>
-<li><code>Experimental</code> standards that are transient and created to test concepts</li>
-</ol>
-<h2 id='candidate-standards'>Candidate Standards</h2>
-<p>The Consumer Data Standards currently include the following candidate standards:</p>
-
-<ul>
-<li><a href="./includes/additional/candidates/telco.html">Candidate standards for the Telecommunications sector</a></li>
-</ul>
-<h2 id='draft-standards'>Draft Standards</h2>
-<p>The Consumer Data Standards do not currently include any draft standards.</p>
-<h2 id='experimental-standards'>Experimental Standards</h2>
-<p>The experimental standards developed by the Data Standards Body are developed in this <a href="https://github.com/ConsumerDataStandardsAustralia/standards-experimental">GitHub repository</a> and are <a href="https://consumerdatastandardsaustralia.github.io/standards-experimental/">published here</a>.</p>
diff --git a/docs/includes/additional/additional20230717-92036-rywnu1 b/docs/includes/additional/additional20230717-92036-rywnu1
deleted file mode 100644
index 93415bd9..00000000
--- a/docs/includes/additional/additional20230717-92036-rywnu1
+++ /dev/null
@@ -1,20 +0,0 @@
-<h1 id='additional-standards'>Additional Standards</h1>
-<p>The Consumer Data Standards also incorporate other non-binding standards that are developed to facilitate consultation and feedback or to facilitate voluntary extension of CDR implementations.</p>
-
-<p>These standards fall into three categories:</p>
-
-<ol>
-<li><code>Candidate</code> standards that are non-binding and stable</li>
-<li><code>Draft</code> standards that are non-binding but volatile as they are under development</li>
-<li><code>Experimental</code> standards that are transient and created to test concepts</li>
-</ol>
-<h2 id='candidate-standards'>Candidate Standards</h2>
-<p>The Consumer Data Standards currently include the following candidate standards:</p>
-
-<ul>
-<li><a href="./includes/additional/candidates/telco.html">Candidate standards for the Telecommunications sector</a></li>
-</ul>
-<h2 id='draft-standards'>Draft Standards</h2>
-<p>The Consumer Data Standards do not currently include any draft standards.</p>
-<h2 id='experimental-standards'>Experimental Standards</h2>
-<p>The experimental standards developed by the Data Standards Body are developed in this <a href="https://github.com/ConsumerDataStandardsAustralia/standards-experimental">GitHub repository</a> and are <a href="https://consumerdatastandardsaustralia.github.io/standards-experimental/">published here</a>.</p>
diff --git a/docs/includes/additional/additional20230721-17819-179l1ax b/docs/includes/additional/additional20230721-17819-179l1ax
deleted file mode 100644
index 93415bd9..00000000
--- a/docs/includes/additional/additional20230721-17819-179l1ax
+++ /dev/null
@@ -1,20 +0,0 @@
-<h1 id='additional-standards'>Additional Standards</h1>
-<p>The Consumer Data Standards also incorporate other non-binding standards that are developed to facilitate consultation and feedback or to facilitate voluntary extension of CDR implementations.</p>
-
-<p>These standards fall into three categories:</p>
-
-<ol>
-<li><code>Candidate</code> standards that are non-binding and stable</li>
-<li><code>Draft</code> standards that are non-binding but volatile as they are under development</li>
-<li><code>Experimental</code> standards that are transient and created to test concepts</li>
-</ol>
-<h2 id='candidate-standards'>Candidate Standards</h2>
-<p>The Consumer Data Standards currently include the following candidate standards:</p>
-
-<ul>
-<li><a href="./includes/additional/candidates/telco.html">Candidate standards for the Telecommunications sector</a></li>
-</ul>
-<h2 id='draft-standards'>Draft Standards</h2>
-<p>The Consumer Data Standards do not currently include any draft standards.</p>
-<h2 id='experimental-standards'>Experimental Standards</h2>
-<p>The experimental standards developed by the Data Standards Body are developed in this <a href="https://github.com/ConsumerDataStandardsAustralia/standards-experimental">GitHub repository</a> and are <a href="https://consumerdatastandardsaustralia.github.io/standards-experimental/">published here</a>.</p>
diff --git a/docs/includes/additional/additional20230710-41010-2lz7rg b/docs/includes/additional/additional20230823-23024-lrwqa8
similarity index 100%
rename from docs/includes/additional/additional20230710-41010-2lz7rg
rename to docs/includes/additional/additional20230823-23024-lrwqa8
diff --git a/docs/includes/additional/candidates/telco.html b/docs/includes/additional/candidates/telco.html
index e4499e68..e2ae31dc 100644
--- a/docs/includes/additional/candidates/telco.html
+++ b/docs/includes/additional/candidates/telco.html
@@ -609,15 +609,7 @@ <h1 id='telco-apis'>Telco APIs</h1><aside class="notice">
 <tr><td><a href='../../../includes/swagger/cds_telco.json'>Telco OpenAPI Specification (JSON)</a></td></tr>
 <tr><td><a href='../../../includes/swagger/cds_telco.yaml'>Telco OpenAPI Specification (YAML)</a></td></tr>
 </table>
-<pre class="highlight diff tab-diff"><code>Updated description of TelcoPaymentScheduleDigitalWallet.name field
-from:
-<span class="gd">- The name assigned to the digital wallet by the owner of the wallet, else the display name provided by the digital wallet provider
-</span>to:
-<span class="gi">+ The display name of the wallet as given by the customer, else a default value defined by the data holder
-</span>
-Replaced FAPI draft references with FAPI 1.0 Final references.
-References pertain to the x-fapi-auth-date header.
-</code></pre><h2 id='get-telco-products'>Get Telco Products</h2>
+<h2 id='get-telco-products'>Get Telco Products</h2>
 <p><a id="opIdlistProducts"></a></p>
 
 <blockquote>
diff --git a/docs/includes/additional/candidates/telco_apis b/docs/includes/additional/candidates/telco_apis
index 67c48ce4..f86b76f8 100644
--- a/docs/includes/additional/candidates/telco_apis
+++ b/docs/includes/additional/candidates/telco_apis
@@ -4,12 +4,3 @@
 <tr><td><a href='../../../includes/swagger/cds_telco.json'>Telco OpenAPI Specification (JSON)</a></td></tr>
 <tr><td><a href='../../../includes/swagger/cds_telco.yaml'>Telco OpenAPI Specification (YAML)</a></td></tr>
 </table>
-<pre class="highlight diff tab-diff"><code>Updated description of TelcoPaymentScheduleDigitalWallet.name field
-from:
-<span class="gd">- The name assigned to the digital wallet by the owner of the wallet, else the display name provided by the digital wallet provider
-</span>to:
-<span class="gi">+ The display name of the wallet as given by the customer, else a default value defined by the data holder
-</span>
-Replaced FAPI draft references with FAPI 1.0 Final references.
-References pertain to the x-fapi-auth-date header.
-</code></pre>
\ No newline at end of file
diff --git a/docs/includes/archives b/docs/includes/archives
index 4ac84228..893a9ed4 100644
--- a/docs/includes/archives
+++ b/docs/includes/archives
@@ -9,6 +9,11 @@
 </tr>
 </thead><tbody>
 <tr>
+<td><a href='https://consumerdatastandardsaustralia.github.io/standards-archives/standards-1.25.0/'>08/07/2023</a></td>
+<td>1.25.0</td>
+<td><a href='https://consumerdatastandardsaustralia.github.io/standards-archives/standards-1.25.0/'>Changes arising from Decision 303 (Maintenance iteration 15) and Decision 288 (Metrics and NFRs)</a></td>
+</tr>
+<tr>
 <td><a href='https://consumerdatastandardsaustralia.github.io/standards-archives/standards-1.24.0/'>07/05/2023</a></td>
 <td>1.24.0</td>
 <td><a href='https://consumerdatastandardsaustralia.github.io/standards-archives/standards-1.24.0/'>Changes arising from Decision 281 (Maintenance iteration 14)</a></td>
diff --git a/docs/includes/cds_admin b/docs/includes/cds_admin
index cd1bbd26..10f9dba7 100644
--- a/docs/includes/cds_admin
+++ b/docs/includes/cds_admin
@@ -192,15 +192,15 @@ This operation may only be called by the CDR Register
 
 <p>This end point is not required to be implemented by the Australian Energy Market Operator, the Australian Energy Regulator or the Department of State administered by the Minister of Victoria administering the National Electricity (Victoria) Act 2005 (Vic).</p>
 
-<p>NOTE: This version must be implemented by <strong>June 13th 2024</strong></p>
+<p>NOTE: This version <strong>MUST</strong> be implemented by <strong>May 13th 2024</strong></p>
 
 <p>Obsolete versions: <a href="includes/obsolete/get-metrics-v1.html">v1</a> <a href="includes/obsolete/get-metrics-v2.html">v2</a>.</p>
 
 <p>Deprecated versions:</p>
 
 <ul>
-<li><a href="includes/obsolete/get-metrics-v3.html">v3</a></li>
-<li><a href="includes/obsolete/get-metrics-v4.html">v4</a> - This version, or v5, must be implemented by <strong>November 1st 2023</strong></li>
+<li><a href="includes/obsolete/get-metrics-v3.html">v3</a> - Implementation not required for Data Holders going live on, or after, 1st November 2023.  Other Data Holders <strong>MAY</strong> retire this version from the earlier of <strong>13th May 2023</strong> or from the time ACCC announce that they no longer call this version</li>
+<li><a href="includes/obsolete/get-metrics-v4.html">v4</a> - This version, or v5, <strong>MUST</strong> be implemented by <strong>November 1st 2023</strong></li>
 </ul>
 
 <p>If the Data Holder supports private_key_jwt client authentication they MUST validate the scope.</p>
diff --git a/docs/includes/changelog b/docs/includes/changelog
index 45d973f4..3fc9f85d 100644
--- a/docs/includes/changelog
+++ b/docs/includes/changelog
@@ -10,6 +10,12 @@
 </tr>
 </thead><tbody>
 <tr>
+<td>23/08/2023</td>
+<td>1.26.0</td>
+<td>Changes to obligations for the implementation of Get Metrics</td>
+<td>See <a href="includes/releasenotes/releasenotes.1.26.0.html">release notes</a> and <a href="https://github.com/ConsumerDataStandardsAustralia/standards/issues/322">Decision 322</a> for details.</td>
+</tr>
+<tr>
 <td>08/07/2023</td>
 <td>1.25.0</td>
 <td>Changes arising from Decision 303 (Maintenance iteration 15) and Decision 288 (Metrics and NFRs)</td>
diff --git a/docs/includes/endpoint-version-schedule/index.html b/docs/includes/endpoint-version-schedule/index.html
index 5abcdd64..e6b0e876 100644
--- a/docs/includes/endpoint-version-schedule/index.html
+++ b/docs/includes/endpoint-version-schedule/index.html
@@ -1294,9 +1294,9 @@ <h2 id='admin-apis'>Admin APIs</h2>
 <td><span class="method get">GET</span></td>
 <td>V3</td>
 <td>2022-10-01</td>
-<td>N/A</td>
+<td>2024-05-13 <strong>&dagger;</strong></td>
 <td>2021-10-06, V1.12.0</td>
-<td>N/A</td>
+<td>2023-07-08, V1.25.0</td>
 </tr>
 <tr>
 <td>Admin APIs</td>
@@ -1307,7 +1307,7 @@ <h2 id='admin-apis'>Admin APIs</h2>
 <td>2023-11-01</td>
 <td>When v5 Implemented</td>
 <td>2023-07-08, V1.25.0</td>
-<td>N/A</td>
+<td>2023-07-08, V1.25.0</td>
 </tr>
 <tr>
 <td>Admin APIs</td>
@@ -1315,12 +1315,19 @@ <h2 id='admin-apis'>Admin APIs</h2>
 <td><code>/admin/metrics</code></td>
 <td><span class="method get">GET</span></td>
 <td>V5</td>
-<td>2024-06-13</td>
+<td>2024-05-13</td>
 <td>N/A</td>
 <td>2023-07-08, V1.25.0</td>
 <td>N/A</td>
 </tr>
 </tbody></table>
+
+<p><strong>&dagger;NOTE:</strong> the details of the retirement date for Get Metrics v3 is as follows:</p>
+
+<ul>
+<li>Implementation of Get Metrics v3 is not required for Data Holders going live on, or after, 1st November 2023</li>
+<li>Other Data Holders <strong>MAY</strong> retire this version from the earlier of <strong>13th May 2023</strong> or from the time ACCC announce that they no longer call this version</li>
+</ul>
 <h1 id='register-apis'>Register APIs</h1>
 <aside class="warning">
   These endpoints are not implemented by Data Holders and Data Recipients. They are hosted by the Register for consumption by participants.
diff --git a/docs/includes/known-issues b/docs/includes/known-issues
index 437a322c..ca9b73cb 100644
--- a/docs/includes/known-issues
+++ b/docs/includes/known-issues
@@ -1,6 +1,8 @@
 <h1 id='known-issues'>Known Issues</h1>
 <p>There are certain aspects of the standards that are actively under review. These known issues are articulated in the following table.</p>
-
+<pre class="highlight diff tab-diff"><code>The known issue related to the incorrect obligation date for
+Get Metrics v5 has been removed as it has been resolved
+</code></pre>
 <table><thead>
 <tr>
 <th style="text-align: left">Issue</th>
@@ -8,10 +10,6 @@
 </tr>
 </thead><tbody>
 <tr>
-<td style="text-align: left">Incorrect obligation date for Get Metrics v5</td>
-<td style="text-align: left">The future dated obligation date has been incorrectly documented in the standards as June 13th 2024.  This was a documentation error when v1.25.0 of the standards were published.  According to the decision of the Data Standards Chair (Decision 288) the obligation date for the implementation of Get Metrics v5 is <strong>May 13th 2024</strong>.  This will be corrected in the next release of the standards.</td>
-</tr>
-<tr>
 <td style="text-align: left">Register APIs use local version of common definitions</td>
 <td style="text-align: left">The Register APIs use a locally defined version of common schema definitions such as <code>ResponseErrorList</code> for error responses. These need to be updated to reference common swagger specifications inherited by the Common Swagger spec.</td>
 </tr>
diff --git a/docs/includes/nfrs b/docs/includes/nfrs
index 22550862..38419d2c 100644
--- a/docs/includes/nfrs
+++ b/docs/includes/nfrs
@@ -141,11 +141,6 @@
 
 <p>For Unattended traffic during high traffic periods only best effort support is required.</p>
 
-<pre class="highlight diff tab-diff"><code>Updated the static site wide TPS thresholds with a graduated set of
-thresholds depending on the number of active authorisations established
-with the data holder
-</code></pre>
-
 <p>For secure traffic (both Customer Present and Unattended) the following traffic thresholds will apply:</p>
 
 <ul>
@@ -177,9 +172,9 @@ with the data holder
 <li>Unattended calls should be managed to avoid short term bursts of traffic</li>
 </ul>
 
-<p><pre class="highlight diff tab-diff"><code><span class="gi">+ Added the Low Velocity Data Sets section
-</span></code></pre><h3 id='low-velocity-data-sets'>Low Velocity Data Sets</h3>
-<p>For endpoints that provide access to data that is low velocity (ie. the data does not change frequently) the Data Recipient Software Product is expected to cache the results of any data they receive and not request the same resource again until the data may reasonably have changed.</p></p>
+<h3 id='low-velocity-data-sets'>Low Velocity Data Sets</h3>
+
+<p>For endpoints that provide access to data that is low velocity (ie. the data does not change frequently) the Data Recipient Software Product is expected to cache the results of any data they receive and not request the same resource again until the data may reasonably have changed.</p>
 
 <p>For low velocity data sets, if the same data is requested repeatedly a Data Holder may reject subsequent requests for the same data during a specified period.</p>
 
diff --git a/docs/includes/obsolete/get-metrics-v3.html b/docs/includes/obsolete/get-metrics-v3.html
index 6b5e0477..c12f1467 100644
--- a/docs/includes/obsolete/get-metrics-v3.html
+++ b/docs/includes/obsolete/get-metrics-v3.html
@@ -282,7 +282,9 @@
         <h1 id='get-metrics-v3'>Get Metrics V3</h1>
 <p>This page documents the deprecated version 3 of the Get Metrics end point.</p>
 
-<p>This version does not yet have an obsolescence date and must continue to be supported by data holders.</p>
+<p>Support for this version is not required for Data Holders going live on, or after, 1st November 2023.</p>
+
+<p>Other Data Holders <strong>MAY</strong> retire this version from the earlier of <strong>13th May 2023</strong> or from the time ACCC announce that they no longer call this version.</p>
 <h2 id='get-metrics'>Get Metrics</h2>
 <p><a id="opIdgetMetrics"></a></p>
 
diff --git a/docs/includes/obsolete/get-metrics-v4.html b/docs/includes/obsolete/get-metrics-v4.html
index eacc5fde..8c205420 100644
--- a/docs/includes/obsolete/get-metrics-v4.html
+++ b/docs/includes/obsolete/get-metrics-v4.html
@@ -285,7 +285,7 @@
         <h1 id='get-metrics-v4'>Get Metrics V4</h1>
 <p>This page documents the deprecated version 4 of the Get Metrics end point.</p>
 
-<p>This version must be implemented by <strong>November 1st 2023</strong> and may be obsoleted once v5 has been implemented</p>
+<p>This version <strong>MUST</strong> be implemented by <strong>November 1st 2023</strong> and <strong>MAY</strong> be retured once v5 has been implemented</p>
 <h2 id='get-metrics'>Get Metrics</h2>
 <p><a id="opIdgetMetrics"></a></p>
 
diff --git a/docs/includes/releasenotes/releasenotes.1.26.0.html b/docs/includes/releasenotes/releasenotes.1.26.0.html
new file mode 100644
index 00000000..c787d76e
--- /dev/null
+++ b/docs/includes/releasenotes/releasenotes.1.26.0.html
@@ -0,0 +1,306 @@
+
+<!doctype html>
+<html>
+  <head>
+    <meta charset="utf-8">
+    <meta content="IE=edge,chrome=1" http-equiv="X-UA-Compatible">
+    <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">
+    <title>Consumer Data Standards - v1.26.0 Release Notes</title>
+    <link href="../../images/favicon.ico" rel="icon" type="image/ico" />
+
+    <style>
+      .highlight table td { padding: 5px; }
+.highlight table pre { margin: 0; }
+.highlight .gh {
+  color: #999999;
+}
+.highlight .sr {
+  color: #f6aa11;
+}
+.highlight .go {
+  color: #888888;
+}
+.highlight .gp {
+  color: #555555;
+}
+.highlight .gs {
+}
+.highlight .gu {
+  color: #aaaaaa;
+}
+.highlight .nb {
+  color: #f6aa11;
+}
+.highlight .cm {
+  color: #75715e;
+}
+.highlight .cp {
+  color: #75715e;
+}
+.highlight .c1 {
+  color: #75715e;
+}
+.highlight .cs {
+  color: #75715e;
+}
+.highlight .c, .highlight .cd {
+  color: #75715e;
+}
+.highlight .err {
+  color: #960050;
+}
+.highlight .gr {
+  color: #960050;
+}
+.highlight .gt {
+  color: #960050;
+}
+.highlight .gd {
+  color: #49483e;
+}
+.highlight .gi {
+  color: #49483e;
+}
+.highlight .ge {
+  color: #49483e;
+}
+.highlight .kc {
+  color: #66d9ef;
+}
+.highlight .kd {
+  color: #66d9ef;
+}
+.highlight .kr {
+  color: #66d9ef;
+}
+.highlight .no {
+  color: #66d9ef;
+}
+.highlight .kt {
+  color: #66d9ef;
+}
+.highlight .mf {
+  color: #ae81ff;
+}
+.highlight .mh {
+  color: #ae81ff;
+}
+.highlight .il {
+  color: #ae81ff;
+}
+.highlight .mi {
+  color: #ae81ff;
+}
+.highlight .mo {
+  color: #ae81ff;
+}
+.highlight .m, .highlight .mb, .highlight .mx {
+  color: #ae81ff;
+}
+.highlight .sc {
+  color: #ae81ff;
+}
+.highlight .se {
+  color: #ae81ff;
+}
+.highlight .ss {
+  color: #ae81ff;
+}
+.highlight .sd {
+  color: #e6db74;
+}
+.highlight .s2 {
+  color: #e6db74;
+}
+.highlight .sb {
+  color: #e6db74;
+}
+.highlight .sh {
+  color: #e6db74;
+}
+.highlight .si {
+  color: #e6db74;
+}
+.highlight .sx {
+  color: #e6db74;
+}
+.highlight .s1 {
+  color: #e6db74;
+}
+.highlight .s {
+  color: #e6db74;
+}
+.highlight .na {
+  color: #a6e22e;
+}
+.highlight .nc {
+  color: #a6e22e;
+}
+.highlight .nd {
+  color: #a6e22e;
+}
+.highlight .ne {
+  color: #a6e22e;
+}
+.highlight .nf {
+  color: #a6e22e;
+}
+.highlight .vc {
+  color: #ffffff;
+}
+.highlight .nn {
+  color: #ffffff;
+}
+.highlight .nl {
+  color: #ffffff;
+}
+.highlight .ni {
+  color: #ffffff;
+}
+.highlight .bp {
+  color: #ffffff;
+}
+.highlight .vg {
+  color: #ffffff;
+}
+.highlight .vi {
+  color: #ffffff;
+}
+.highlight .nv {
+  color: #ffffff;
+}
+.highlight .w {
+  color: #ffffff;
+}
+.highlight {
+  color: #ffffff;
+}
+.highlight .n, .highlight .py, .highlight .nx {
+  color: #ffffff;
+}
+.highlight .ow {
+  color: #f92672;
+}
+.highlight .nt {
+  color: #f92672;
+}
+.highlight .k, .highlight .kv {
+  color: #f92672;
+}
+.highlight .kn {
+  color: #f92672;
+}
+.highlight .kp {
+  color: #f92672;
+}
+.highlight .o {
+  color: #f92672;
+}
+    </style>
+    <link href="../../stylesheets/screen.css" rel="stylesheet" media="screen" />
+    <link href="../../stylesheets/print.css" rel="stylesheet" media="print" />
+      <script src="../../javascripts/all_nosearch.js"></script>
+  </head>
+
+  <body class="no-code-layout includes includes_releasenotes includes_releasenotes_releasenotes" data-languages="[]">
+    <a href="#" id="nav-button">
+      <span>
+        NAV
+        <img src="../../images/navbar.png" alt="Navbar" />
+      </span>
+    </a>
+    <div class="toc-wrapper">
+      <img src="../../images/logo.png" class="logo" alt="Logo" />
+      <ul id="toc" class="toc-list-h1">
+          <li>
+            <a href="#v1-26-0-release-notes" class="toc-h1 toc-link" data-title="V1.26.0 Release Notes">V1.26.0 Release Notes</a>
+              <ul class="toc-list-h2">
+                  <li>
+                    <a href="#changes-made" class="toc-h2 toc-link" data-title="Changes Made">Changes Made</a>
+                  </li>
+                  <li>
+                    <a href="#introduction" class="toc-h2 toc-link" data-title="Introduction">Introduction</a>
+                  </li>
+                  <li>
+                    <a href="#high-level-standards" class="toc-h2 toc-link" data-title="High Level Standards">High Level Standards</a>
+                  </li>
+                  <li>
+                    <a href="#api-end-points" class="toc-h2 toc-link" data-title="API End Points">API End Points</a>
+                  </li>
+                  <li>
+                    <a href="#information-security-profile" class="toc-h2 toc-link" data-title="Information Security Profile">Information Security Profile</a>
+                  </li>
+                  <li>
+                    <a href="#register-standards" class="toc-h2 toc-link" data-title="Register Standards">Register Standards</a>
+                  </li>
+                  <li>
+                    <a href="#consumer-experience" class="toc-h2 toc-link" data-title="Consumer Experience">Consumer Experience</a>
+                  </li>
+                  <li>
+                    <a href="#non-functional-requirements" class="toc-h2 toc-link" data-title="Non Functional Requirements">Non Functional Requirements</a>
+                  </li>
+                  <li>
+                    <a href="#known-issues" class="toc-h2 toc-link" data-title="Known Issues">Known Issues</a>
+                  </li>
+              </ul>
+          </li>
+      </ul>
+        <ul class="toc-footer">
+            <li><a href='../../index.html'>Consumer Data Standards</a></li>
+        </ul>
+    </div>
+    <div class="page-wrapper">
+      <div class="content">
+        <h1 id='v1-26-0-release-notes'>V1.26.0 Release Notes</h1>
+<p>Release notes for version v1.26.0 of the <a href="../../">CDR Standards</a>.</p>
+<h2 id='changes-made'>Changes Made</h2><h3 id='change-requests'>Change Requests</h3>
+<p>This release addresses the following minor defects raised on <a href="https://github.com/ConsumerDataStandardsAustralia/standards-staging/issues">Standards Staging</a>:</p>
+
+<ul>
+<li>TBD</li>
+</ul>
+
+<p>This release addresses the following change requests raised on <a href="https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues">Standards Maintenance</a>:</p>
+
+<ul>
+<li>None</li>
+</ul>
+<h3 id='decision-proposals'>Decision Proposals</h3>
+<p>This release addresses the following Decision Proposals published on <a href="https://github.com/ConsumerDataStandardsAustralia/standards/issues">Standards</a>:</p>
+
+<ul>
+<li><a href="https://github.com/ConsumerDataStandardsAustralia/standards/issues/322">Decision Proposal 322 - Update Get Metrics Endpoint Schedule</a></li>
+</ul>
+<h2 id='introduction'>Introduction</h2>
+<p>No Change</p>
+<h2 id='high-level-standards'>High Level Standards</h2>
+<p>No Change</p>
+<h2 id='api-end-points'>API End Points</h2>
+<table><thead>
+<tr>
+<th>Change</th>
+<th>Description</th>
+<th>Link</th>
+</tr>
+</thead><tbody>
+<tr>
+<td>Modified Get Metrics Obligations</td>
+<td>Changes to the obligation dates for Get Metrics v3 as determined in <a href="https://github.com/ConsumerDataStandardsAustralia/standards/issues/322">Decision 322</a></td>
+<td><a href="../../#admin-apis">Admin APIs</a></td>
+</tr>
+</tbody></table>
+<h2 id='information-security-profile'>Information Security Profile</h2>
+<p>No Change</p>
+<h2 id='register-standards'>Register Standards</h2>
+<p>No Change</p>
+<h2 id='consumer-experience'>Consumer Experience</h2>
+<p>No Change</p>
+<h2 id='non-functional-requirements'>Non Functional Requirements</h2>
+<p>No Change</p>
+<h2 id='known-issues'>Known Issues</h2>
+<p>Resolved the known issue related to the incorrect obligation date for Get Metrics v5</p>
+
+      </div>
+    </div>
+  </body>
+</html>
diff --git a/docs/includes/swagger/cds_admin.json b/docs/includes/swagger/cds_admin.json
index 39dee4f9..d3b4f529 100644
--- a/docs/includes/swagger/cds_admin.json
+++ b/docs/includes/swagger/cds_admin.json
@@ -12,7 +12,7 @@
       "url" : "https://opensource.org/licenses/MIT"
     },
     "title" : "CDR Admin API",
-    "version" : "1.25.0"
+    "version" : "1.26.0"
   },
   "servers" : [ {
     "url" : "https://data.holder.com.au/cds-au/v1"
@@ -103,7 +103,7 @@
     },
     "/admin/metrics" : {
       "get" : {
-        "description" : "This end point allows the ACCC to obtain operational statistics from the Data Holder (at the Data Holder Brand level) on the operation of their CDR compliant implementation. The statistics obtainable from this end point are determined by the non-functional requirements for the CDR regime.\n\nThis end point is not required to be implemented by the Australian Energy Market Operator, the Australian Energy Regulator or the Department of State administered by the Minister of Victoria administering the National Electricity (Victoria) Act 2005 (Vic).\n\nNOTE: This version must be implemented by **June 13th 2024**\n\nObsolete versions: [v1](includes/obsolete/get-metrics-v1.html) [v2](includes/obsolete/get-metrics-v2.html).\n\nDeprecated versions:\n\n- [v3](includes/obsolete/get-metrics-v3.html)\n- [v4](includes/obsolete/get-metrics-v4.html) - This version, or v5, must be implemented by **November 1st 2023**\n\nIf the Data Holder supports private_key_jwt client authentication they MUST validate the scope.",
+        "description" : "This end point allows the ACCC to obtain operational statistics from the Data Holder (at the Data Holder Brand level) on the operation of their CDR compliant implementation. The statistics obtainable from this end point are determined by the non-functional requirements for the CDR regime.\n\nThis end point is not required to be implemented by the Australian Energy Market Operator, the Australian Energy Regulator or the Department of State administered by the Minister of Victoria administering the National Electricity (Victoria) Act 2005 (Vic).\n\nNOTE: This version **MUST** be implemented by **May 13th 2024**\n\nObsolete versions: [v1](includes/obsolete/get-metrics-v1.html) [v2](includes/obsolete/get-metrics-v2.html).\n\nDeprecated versions:\n\n- [v3](includes/obsolete/get-metrics-v3.html) - Implementation not required for Data Holders going live on, or after, 1st November 2023.  Other Data Holders **MAY** retire this version from the earlier of **13th May 2023** or from the time ACCC announce that they no longer call this version\n- [v4](includes/obsolete/get-metrics-v4.html) - This version, or v5, **MUST** be implemented by **November 1st 2023**\n\nIf the Data Holder supports private_key_jwt client authentication they MUST validate the scope.",
         "operationId" : "getMetrics",
         "parameters" : [ {
           "description" : "The period of metrics to be requested. Values can be CURRENT (meaning metrics for current period, dependent on the metric type), HISTORIC (meaning metrics for previous period, depending on the metric type) or ALL. If absent the default is ALL.",
diff --git a/docs/includes/swagger/cds_admin.yaml b/docs/includes/swagger/cds_admin.yaml
index 4224a198..4d9c5e2b 100644
--- a/docs/includes/swagger/cds_admin.yaml
+++ b/docs/includes/swagger/cds_admin.yaml
@@ -11,7 +11,7 @@ info:
     name: MIT License
     url: https://opensource.org/licenses/MIT
   title: CDR Admin API
-  version: 1.25.0
+  version: 1.26.0
 servers:
 - url: https://data.holder.com.au/cds-au/v1
 paths:
@@ -99,14 +99,14 @@ paths:
 
         This end point is not required to be implemented by the Australian Energy Market Operator, the Australian Energy Regulator or the Department of State administered by the Minister of Victoria administering the National Electricity (Victoria) Act 2005 (Vic).
 
-        NOTE: This version must be implemented by **June 13th 2024**
+        NOTE: This version **MUST** be implemented by **May 13th 2024**
 
         Obsolete versions: [v1](includes/obsolete/get-metrics-v1.html) [v2](includes/obsolete/get-metrics-v2.html).
 
         Deprecated versions:
 
-        - [v3](includes/obsolete/get-metrics-v3.html)
-        - [v4](includes/obsolete/get-metrics-v4.html) - This version, or v5, must be implemented by **November 1st 2023**
+        - [v3](includes/obsolete/get-metrics-v3.html) - Implementation not required for Data Holders going live on, or after, 1st November 2023.  Other Data Holders **MAY** retire this version from the earlier of **13th May 2023** or from the time ACCC announce that they no longer call this version
+        - [v4](includes/obsolete/get-metrics-v4.html) - This version, or v5, **MUST** be implemented by **November 1st 2023**
 
         If the Data Holder supports private_key_jwt client authentication they MUST validate the scope.
       operationId: getMetrics
diff --git a/docs/includes/swagger/cds_banking.json b/docs/includes/swagger/cds_banking.json
index 34a6ea49..2e1b188a 100644
--- a/docs/includes/swagger/cds_banking.json
+++ b/docs/includes/swagger/cds_banking.json
@@ -12,7 +12,7 @@
       "url" : "https://opensource.org/licenses/MIT"
     },
     "title" : "CDR Banking API",
-    "version" : "1.25.0"
+    "version" : "1.26.0"
   },
   "servers" : [ {
     "url" : "https://data.holder.com.au/cds-au/v1"
diff --git a/docs/includes/swagger/cds_banking.yaml b/docs/includes/swagger/cds_banking.yaml
index 4aa84cfd..71c6c308 100644
--- a/docs/includes/swagger/cds_banking.yaml
+++ b/docs/includes/swagger/cds_banking.yaml
@@ -11,7 +11,7 @@ info:
     name: MIT License
     url: https://opensource.org/licenses/MIT
   title: CDR Banking API
-  version: 1.25.0
+  version: 1.26.0
 servers:
 - url: https://data.holder.com.au/cds-au/v1
 paths:
diff --git a/docs/includes/swagger/cds_common.json b/docs/includes/swagger/cds_common.json
index 21b25e4d..a008df9e 100644
--- a/docs/includes/swagger/cds_common.json
+++ b/docs/includes/swagger/cds_common.json
@@ -12,7 +12,7 @@
       "url" : "https://opensource.org/licenses/MIT"
     },
     "title" : "CDR Common API",
-    "version" : "1.25.0"
+    "version" : "1.26.0"
   },
   "servers" : [ {
     "url" : "https://data.holder.com.au/cds-au/v1"
diff --git a/docs/includes/swagger/cds_common.yaml b/docs/includes/swagger/cds_common.yaml
index 1191a04d..11e75e9c 100644
--- a/docs/includes/swagger/cds_common.yaml
+++ b/docs/includes/swagger/cds_common.yaml
@@ -11,7 +11,7 @@ info:
     name: MIT License
     url: https://opensource.org/licenses/MIT
   title: CDR Common API
-  version: 1.25.0
+  version: 1.26.0
 servers:
 - url: https://data.holder.com.au/cds-au/v1
 paths:
diff --git a/docs/includes/swagger/cds_dcr.json b/docs/includes/swagger/cds_dcr.json
index ba6399e7..f157e1b4 100644
--- a/docs/includes/swagger/cds_dcr.json
+++ b/docs/includes/swagger/cds_dcr.json
@@ -3,7 +3,7 @@
   "info" : {
     "description" : "This specification defines the APIs for Data Holders exposing Dynamic Client Registration endpoints.",
     "title" : "CDR Dynamic Client Registration API",
-    "version" : "1.25.0"
+    "version" : "1.26.0"
   },
   "servers" : [ {
     "url" : "https://data.holder.com.au/"
diff --git a/docs/includes/swagger/cds_dcr.yaml b/docs/includes/swagger/cds_dcr.yaml
index 015a04fc..b64bb755 100644
--- a/docs/includes/swagger/cds_dcr.yaml
+++ b/docs/includes/swagger/cds_dcr.yaml
@@ -3,7 +3,7 @@ info:
   description: This specification defines the APIs for Data Holders exposing Dynamic
     Client Registration endpoints.
   title: CDR Dynamic Client Registration API
-  version: 1.25.0
+  version: 1.26.0
 servers:
 - url: https://data.holder.com.au/
 paths:
diff --git a/docs/includes/swagger/cds_energy.json b/docs/includes/swagger/cds_energy.json
index 8ea5cf26..27cb88cc 100644
--- a/docs/includes/swagger/cds_energy.json
+++ b/docs/includes/swagger/cds_energy.json
@@ -3,7 +3,7 @@
   "info" : {
     "description" : "Consumer Data Right end points and payloads for the Energy sector",
     "title" : "CDR Energy API",
-    "version" : "1.25.0"
+    "version" : "1.26.0"
   },
   "servers" : [ {
     "url" : "/"
diff --git a/docs/includes/swagger/cds_energy.yaml b/docs/includes/swagger/cds_energy.yaml
index e3a34b42..231ae892 100644
--- a/docs/includes/swagger/cds_energy.yaml
+++ b/docs/includes/swagger/cds_energy.yaml
@@ -2,7 +2,7 @@ openapi: 3.0.3
 info:
   description: Consumer Data Right end points and payloads for the Energy sector
   title: CDR Energy API
-  version: 1.25.0
+  version: 1.26.0
 servers:
 - url: /
 paths:
diff --git a/docs/includes/swagger/cds_energy_sdh.json b/docs/includes/swagger/cds_energy_sdh.json
index bea5cd11..83df0445 100644
--- a/docs/includes/swagger/cds_energy_sdh.json
+++ b/docs/includes/swagger/cds_energy_sdh.json
@@ -3,7 +3,7 @@
   "info" : {
     "description" : "Consumer Data Right end points and payloads for Secondary Data Holder for the Energy sector",
     "title" : "CDR Energy Secondary Data Holder API",
-    "version" : "1.25.0"
+    "version" : "1.26.0"
   },
   "servers" : [ {
     "url" : "/"
diff --git a/docs/includes/swagger/cds_energy_sdh.yaml b/docs/includes/swagger/cds_energy_sdh.yaml
index 205dace7..e917ee2c 100644
--- a/docs/includes/swagger/cds_energy_sdh.yaml
+++ b/docs/includes/swagger/cds_energy_sdh.yaml
@@ -3,7 +3,7 @@ info:
   description: Consumer Data Right end points and payloads for Secondary Data Holder
     for the Energy sector
   title: CDR Energy Secondary Data Holder API
-  version: 1.25.0
+  version: 1.26.0
 servers:
 - url: /
 paths:
diff --git a/docs/includes/swagger/cds_register.json b/docs/includes/swagger/cds_register.json
index 77f75c20..67b17f36 100644
--- a/docs/includes/swagger/cds_register.json
+++ b/docs/includes/swagger/cds_register.json
@@ -2,7 +2,7 @@
   "openapi" : "3.0.3",
   "info" : {
     "title" : "CDR Participant Discovery API",
-    "version" : "1.25.0"
+    "version" : "1.26.0"
   },
   "servers" : [ {
     "url" : "https://<register-base-url>/"
diff --git a/docs/includes/swagger/cds_register.yaml b/docs/includes/swagger/cds_register.yaml
index 59cef5e5..2b68399c 100644
--- a/docs/includes/swagger/cds_register.yaml
+++ b/docs/includes/swagger/cds_register.yaml
@@ -1,7 +1,7 @@
 openapi: 3.0.3
 info:
   title: CDR Participant Discovery API
-  version: 1.25.0
+  version: 1.26.0
 servers:
 - url: https://<register-base-url>/
 paths:
diff --git a/docs/includes/swagger/cds_telco.json b/docs/includes/swagger/cds_telco.json
index d2833d51..75e68814 100644
--- a/docs/includes/swagger/cds_telco.json
+++ b/docs/includes/swagger/cds_telco.json
@@ -12,7 +12,7 @@
       "url" : "https://opensource.org/licenses/MIT"
     },
     "title" : "CDR Telco API",
-    "version" : "1.25.0"
+    "version" : "1.26.0"
   },
   "servers" : [ {
     "url" : "https://data.holder.com.au/cds-au/v1"
diff --git a/docs/includes/swagger/cds_telco.yaml b/docs/includes/swagger/cds_telco.yaml
index eadaadf8..fe6475bd 100644
--- a/docs/includes/swagger/cds_telco.yaml
+++ b/docs/includes/swagger/cds_telco.yaml
@@ -11,7 +11,7 @@ info:
     name: MIT License
     url: https://opensource.org/licenses/MIT
   title: CDR Telco API
-  version: 1.25.0
+  version: 1.26.0
 servers:
 - url: https://data.holder.com.au/cds-au/v1
 paths:
diff --git a/docs/index.html b/docs/index.html
index cf2f6941..100da1e1 100644
--- a/docs/index.html
+++ b/docs/index.html
@@ -1431,7 +1431,7 @@ <h1 id='introduction'>Introduction</h1>
 
 <h2 id='version'>Version</h2>
 
-<p>These standards represent version 1.25.0 of the high level standards.  See the <a href="#versioning">versioning section</a> for more information on how versions are managed in the standard.</p>
+<p>These standards represent version 1.26.0 of the high level standards.  See the <a href="#versioning">versioning section</a> for more information on how versions are managed in the standard.</p>
 
 <h2 id='interpretation'>Interpretation</h2>
 
@@ -1443,10 +1443,12 @@ <h2 id='future-dated-obligations'>Future Dated Obligations</h2>
 
 <p>The table below highlights these areas of the standards.</p>
 
-<pre class="highlight diff tab-diff"><code>Removed legacy obligation dates more than 6 months in the past
-Fixed spelling of "Register"
+<pre class="highlight diff tab-diff"><code>Added the retirement details for Get Metrics v3
 
-Added FDOs for decision 288 and 303
+Corrected the obligation date for Get Metrics v5
+
+Replaced the term `obsolete` with `retire` to clarify the
+intent of these statements
 </code></pre>
 
 <table><thead>
@@ -1458,17 +1460,17 @@ <h2 id='future-dated-obligations'>Future Dated Obligations</h2>
 </thead><tbody>
 <tr>
 <td><a href="#get-account-detail">Get Account Detail V1</a></td>
-<td>Data holders <strong>MAY</strong> obsolete version 1 of this end point from February 28th 2023.  Data recipients <strong>MUST</strong> upgrade their implementations to use version 2 by this time</td>
+<td>Data holders <strong>MAY</strong> retire version 1 of this end point from February 28th 2023.  Data recipients <strong>MUST</strong> upgrade their implementations to use version 2 by this time</td>
 <td>February 28th 2023</td>
 </tr>
 <tr>
 <td><a href="#get-product-detail">Get Product Detail V3</a></td>
-<td>Data holders <strong>MAY</strong> obsolete version 3 of this end point from February 28th 2023.  Data recipients <strong>MUST</strong> upgrade their implementations to use version 4 by this time</td>
+<td>Data holders <strong>MAY</strong> retire version 3 of this end point from February 28th 2023.  Data recipients <strong>MUST</strong> upgrade their implementations to use version 4 by this time</td>
 <td>February 28th 2023</td>
 </tr>
 <tr>
 <td><a href="#get-customer-detail">Get Customer Detail V1</a></td>
-<td>Data holders <strong>MAY</strong> obsolete version 1 of this end point from February 28th 2023.  Data recipients <strong>MUST</strong> upgrade their implementations to use version 2 by this time</td>
+<td>Data holders <strong>MAY</strong> retire version 1 of this end point from February 28th 2023.  Data recipients <strong>MUST</strong> upgrade their implementations to use version 2 by this time</td>
 <td>February 28th 2023</td>
 </tr>
 <tr>
@@ -1508,32 +1510,32 @@ <h2 id='future-dated-obligations'>Future Dated Obligations</h2>
 </tr>
 <tr>
 <td><a href="#get-generic-plan-detail">Get Generic Plan Detail V2</a></td>
-<td><ul><li>Data Holders <strong>MUST</strong> implement v2 of this endpoint by <strong>November 1st 2023</strong></li><li>Data Holders <strong>MAY</strong> obsolete v1 of this endpoint from <strong>September 9th 2024</strong></li></ul></td>
+<td><ul><li>Data Holders <strong>MUST</strong> implement v2 of this endpoint by <strong>November 1st 2023</strong></li><li>Data Holders <strong>MAY</strong> retire v1 of this endpoint from <strong>September 9th 2024</strong></li></ul></td>
 <td>November 1st 2023</td>
 </tr>
 <tr>
 <td><a href="#get-account-detail">Get Energy Account Detail V3</a></td>
-<td><ul><li>Data Holders <strong>MUST</strong> implement v3 of this endpoint by <strong>November 1st 2023</strong></li><li>Data Holders <strong>MAY</strong> obsolete v2 of this endpoint from <strong>September 9th 2024</strong></li></ul></td>
+<td><ul><li>Data Holders <strong>MUST</strong> implement v3 of this endpoint by <strong>November 1st 2023</strong></li><li>Data Holders <strong>MAY</strong> retire v2 of this endpoint from <strong>September 9th 2024</strong></li></ul></td>
 <td>November 1st 2023</td>
 </tr>
 <tr>
 <td><a href="#get-billing-for-account">Get Billing For Account V2</a></td>
-<td><ul><li>Data Holders <strong>MUST</strong> implement v2 of this endpoint by <strong>November 1st 2023</strong></li><li>Data Holders <strong>MAY</strong> obsolete v1 of this endpoint from <strong>September 9th 2024</strong></li></ul></td>
+<td><ul><li>Data Holders <strong>MUST</strong> implement v2 of this endpoint by <strong>November 1st 2023</strong></li><li>Data Holders <strong>MAY</strong> retire v1 of this endpoint from <strong>September 9th 2024</strong></li></ul></td>
 <td>November 1st 2023</td>
 </tr>
 <tr>
 <td><a href="#get-bulk-billing">Get Bulk Billing V2</a></td>
-<td><ul><li>Data Holders <strong>MUST</strong> implement v2 of this endpoint by <strong>November 1st 2023</strong></li><li>Data Holders <strong>MAY</strong> obsolete v1 of this endpoint from <strong>September 9th 2024</strong></li></ul></td>
+<td><ul><li>Data Holders <strong>MUST</strong> implement v2 of this endpoint by <strong>November 1st 2023</strong></li><li>Data Holders <strong>MAY</strong> retire v1 of this endpoint from <strong>September 9th 2024</strong></li></ul></td>
 <td>November 1st 2023</td>
 </tr>
 <tr>
 <td><a href="#get-billing-for-specific-accounts">Get Billing For Specific Accounts V2</a></td>
-<td><ul><li>Data Holders <strong>MUST</strong> implement v2 of this endpoint by <strong>November 1st 2023</strong></li><li>Data Holders <strong>MAY</strong> obsolete v1 of this endpoint from <strong>September 9th 2024</strong></li></ul></td>
+<td><ul><li>Data Holders <strong>MUST</strong> implement v2 of this endpoint by <strong>November 1st 2023</strong></li><li>Data Holders <strong>MAY</strong> retire v1 of this endpoint from <strong>September 9th 2024</strong></li></ul></td>
 <td>November 1st 2023</td>
 </tr>
 <tr>
 <td><a href="#get-metrics">Get Metrics V4</a></td>
-<td><ul><li>Data Holders <strong>MUST</strong> implement v4 or V5 of this endpoint by <strong>November 1st 2023</strong></li><li>Data Holders <strong>MAY</strong> deprecate v4 of this endpoint once V5 is implemented**</li></ul></td>
+<td><ul><li>Data Holders <strong>MUST</strong> implement v4 or V5 of this endpoint by <strong>November 1st 2023</strong></li><li>Data Holders <strong>MAY</strong> retire v4 of this endpoint once V5 is implemented</li></ul></td>
 <td>November 1st 2023</td>
 </tr>
 <tr>
@@ -1553,29 +1555,33 @@ <h2 id='future-dated-obligations'>Future Dated Obligations</h2>
 </tr>
 <tr>
 <td><a href="#get-scheduled-payments-for-account">Get Scheduled Payments for Account V2</a></td>
-<td><ul><li>Data Holders <strong>MUST</strong> implement v2 of this endpoint by <strong>March 11th 2024</strong></li><li>Data Holders <strong>MAY</strong> obsolete v1 of this endpoint from <strong>September 9th 2024</strong></li></ul></td>
+<td><ul><li>Data Holders <strong>MUST</strong> implement v2 of this endpoint by <strong>March 11th 2024</strong></li><li>Data Holders <strong>MAY</strong> retire v1 of this endpoint from <strong>September 9th 2024</strong></li></ul></td>
 <td>March 11th 2024</td>
 </tr>
 <tr>
 <td><a href="#get-scheduled-payments-bulk">Get Scheduled Payments Bulk V2</a></td>
-<td><ul><li>Data Holders <strong>MUST</strong> implement v2 of this endpoint by <strong>March 11th 2024</strong></li><li>Data Holders <strong>MAY</strong> obsolete v1 of this endpoint from <strong>September 9th 2024</strong></li></ul></td>
+<td><ul><li>Data Holders <strong>MUST</strong> implement v2 of this endpoint by <strong>March 11th 2024</strong></li><li>Data Holders <strong>MAY</strong> retire v1 of this endpoint from <strong>September 9th 2024</strong></li></ul></td>
 <td>March 11th 2024</td>
 </tr>
 <tr>
 <td><a href="#get-scheduled-payments-for-specific-accounts">Get Scheduled Payments For Specific Accounts V2</a></td>
-<td><ul><li>Data Holders <strong>MUST</strong> implement v2 of this endpoint by <strong>March 11th 2024</strong></li><li>Data Holders <strong>MAY</strong> obsolete v1 of this endpoint from <strong>September 9th 2024</strong></li></ul></td>
+<td><ul><li>Data Holders <strong>MUST</strong> implement v2 of this endpoint by <strong>March 11th 2024</strong></li><li>Data Holders <strong>MAY</strong> retire v1 of this endpoint from <strong>September 9th 2024</strong></li></ul></td>
 <td>March 11th 2024</td>
 </tr>
 <tr>
+<td><a href="#get-metrics">Get Metrics V3</a></td>
+<td><ul><li>Data Holders <strong>MAY</strong> retire v3 of this endpoint by the earlier of <strong>13th May 2024</strong> or when the ACCC announce that this version is no longer being called</li><li>Data Holders going live on, or after, 1st November 2023 are not required to support this version</li></ul></td>
+<td>May 13th 2024</td>
+</tr>
+<tr>
 <td><a href="#get-metrics">Get Metrics V5</a></td>
-<td><ul><li>Data Holders <strong>MUST</strong> implement V5 of this endpoint by <strong>June 13th 2024</strong></li><li>Data Holders <strong>MAY</strong> deprecate v4 of this endpoint once V5 is implemented**</li></ul></td>
-<td>June 13th 2024</td>
+<td><ul><li>Data Holders <strong>MUST</strong> implement v5 of this endpoint by <strong>May 13th 2024</strong></li><li>Data Holders <strong>MAY</strong> deprecate v4 of this endpoint once V5 is implemented</li></ul></td>
+<td>May 13th 2024</td>
 </tr>
 </tbody></table>
 
-<h2 id='register-implementation-schedule'>Register Implementation Schedule</h2><pre class="highlight diff tab-diff"><code>Removed the dependency schedule content for the Register APIs
-and linked to the ACCC implementation schedule.
-</code></pre>
+<h2 id='register-implementation-schedule'>Register Implementation Schedule</h2>
+
 <p>The implementation of the Register APIs is managed by the ACCC.</p>
 
 <p>Their implementation schedule is <a href="https://consumerdataright.atlassian.net/wiki/spaces/DP/pages/30081043/Delivery+Dates">published here</a>.</p>
@@ -1584,12 +1590,8 @@ <h2 id='endpoint-version-schedule'>Endpoint Version Schedule</h2>
 
 <p>A table-view of all endpoint versioning is available <a href='includes/endpoint-version-schedule/#endpoint-version-schedule'>here</a>.</p>
 
-<h2 id='normative-references'>Normative References</h2><pre class="highlight diff tab-diff"><code>Removed legacy FAPI references:
-<span class="gd">- FAPI-R-Draft
-- FAPI-RW-Draft
-</span>
-Updated PAR references to refer to RFC9126
-</code></pre>
+<h2 id='normative-references'>Normative References</h2>
+
 <table><thead>
 <tr>
 <th><strong>Reference</strong></th>
@@ -1753,6 +1755,7 @@ <h2 id='normative-references'>Normative References</h2><pre class="highlight dif
 <td>Sep 2021</td>
 </tr>
 </tbody></table>
+
 <h2 id='informative-references'>Informative References</h2>
 
 <table><thead>
@@ -2102,9 +2105,7 @@ <h3 id='request-headers'>Request Headers</h3>
 <code>Accept-Encoding: charset=UTF-8</code><br>
 <code>Accept: AppliCAtion/JSon;Charset=uTf-8</code>  </p>
 </blockquote>
-<pre class="highlight diff tab-diff"><code>Replaced FAPI draft references with FAPI 1.0 Final references.
-References pertain to the x-fapi-auth-date header.
-</code></pre>
+
 <table><thead>
 <tr>
 <th>Header Field</th>
@@ -4114,13 +4115,15 @@ <h2 id='withdrawal-standards'>Withdrawal Standards</h2>
 </tbody></table>
 <h1 style="display:none"></h1>
 <h1 id='security-profile'>Security Profile</h1>
-<h2 id='overview'>Overview</h2><pre class="highlight diff tab-diff"><code>Removed legacy phasing of FAPI draft specifications. Only FAPI 1.0 Final is relied upon.
-</code></pre>
+<h2 id='overview'>Overview</h2>
+
 <p>This information security profile builds upon the foundations of the <a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html">Financial-grade API Advanced Profile</a> <strong><a href="#nref-FAPI-1-0-Advanced">[FAPI-1.0-Advanced]</a></strong> and other standards relating to
 <a href="http://openid.net/specs/openid-connect-core-1_0.html">Open ID Connect 1.0</a> <strong><a href="#nref-OIDC">[OIDC]</a></strong>.</p>
 
 <p>For information on the specific normative references that underpin this profile refer to the <a href="#normative-references">Normative References section</a>.</p>
+
 <h3 id='symbols-and-abbreviated-terms'>Symbols and Abbreviated terms</h3>
+
 <ul>
 <li>  <strong>API</strong>: Application Programming Interface</li>
 <li>  <strong>CA</strong>: Certificate Authority</li>
@@ -4284,14 +4287,10 @@ <h3 id='baseline-security-provisions'>Baseline Security Provisions</h3><h4 id='d
 <li>the addition of any requirements beyond normal data holder practices for verification code delivery</li>
 <li>providing or requesting additional information beyond normal data holder practices for verification code delivery</li>
 <li>offering additional or alternative services</li>
-<li>reference or inclusion of other documents</li>
-</ul>
-<pre class="highlight diff tab-diff"><code>Removed legacy phasing requirements for FAPI 1.0 Final
-</code></pre>
-<ul>
-<li>Data Holders <strong>MUST</strong> support FAPI 1.0 Advanced Profile (<strong><a href="#nref-FAPI-1-0-Advanced">[FAPI-1.0-Advanced]</a></strong>).</li>
-<li>Data Holders <strong>MUST</strong> support Authorization Code Flow.<br></li>
-<li>Data Holders <strong>MUST</strong> support the OIDC Hybrid Flow.</li>
+<li><p>reference or inclusion of other documents</p></li>
+<li><p>Data Holders <strong>MUST</strong> support FAPI 1.0 Advanced Profile (<strong><a href="#nref-FAPI-1-0-Advanced">[FAPI-1.0-Advanced]</a></strong>).</p></li>
+<li><p>Data Holders <strong>MUST</strong> support Authorization Code Flow.  </p></li>
+<li><p>Data Holders <strong>MUST</strong> support the OIDC Hybrid Flow.</p></li>
 </ul>
 
 <p><strong>From July 10th 2023 (FAPI 1.0 Migration Phase 4),</strong>   </p>
@@ -4303,16 +4302,12 @@ <h4 id='data-recipient-software-products'>Data Recipient Software Products</h4>
 <p>The following statements are applicable to both the OIDC Hybrid Flow and Authorization Code Flow:</p>
 
 <ul>
-<li>Data Recipient Software Products <strong>SHOULD</strong> record the following information each time an authorisation flow is executed: username (consumer’s ID at the Data Recipient Software Product), timestamp, IP, consent scopes and duration.</li>
-</ul>
-<pre class="highlight diff tab-diff"><code>Removed legacy phasing requirements for FAPI 1.0 Final
-</code></pre>
-<ul>
-<li>Data Recipient Software Products <strong>SHOULD NOT</strong> reuse &quot;authorization_code&quot; values, and if reused, it will be rejected.</li>
-<li>Data Recipient Software Products <strong>MAY</strong> send requests with a &quot;x-fapi-customer-ip-address&quot; header containing a valid IPv4 or IPv6 address.</li>
-<li>Data Recipient Software Products <strong>MUST</strong> support FAPI 1.0 Advanced Profile (<strong><a href="#nref-FAPI-1-0-Advanced">[FAPI-1.0-Advanced]</a></strong>).</li>
-<li>Data Recipient Software Products <strong>MUST</strong> use <strong><a href="#nref-RFC9126">[RFC9126]</a></strong> (PAR) with <strong><a href="#nref-PKCE">[PKCE]</a></strong> (<strong><a href="#nref-RFC7636">[RFC7636]</a></strong>) and, if supported, <strong>MUST</strong> use S256 as the code challenge method.</li>
-<li>Data Recipient Software Products <strong>SHOULD</strong> use Authorization Code Flow.</li>
+<li><p>Data Recipient Software Products <strong>SHOULD</strong> record the following information each time an authorisation flow is executed: username (consumer’s ID at the Data Recipient Software Product), timestamp, IP, consent scopes and duration.</p></li>
+<li><p>Data Recipient Software Products <strong>SHOULD NOT</strong> reuse &quot;authorization_code&quot; values, and if reused, it will be rejected.</p></li>
+<li><p>Data Recipient Software Products <strong>MAY</strong> send requests with a &quot;x-fapi-customer-ip-address&quot; header containing a valid IPv4 or IPv6 address.</p></li>
+<li><p>Data Recipient Software Products <strong>MUST</strong> support FAPI 1.0 Advanced Profile (<strong><a href="#nref-FAPI-1-0-Advanced">[FAPI-1.0-Advanced]</a></strong>).</p></li>
+<li><p>Data Recipient Software Products <strong>MUST</strong> use <strong><a href="#nref-RFC9126">[RFC9126]</a></strong> (PAR) with <strong><a href="#nref-PKCE">[PKCE]</a></strong> (<strong><a href="#nref-RFC7636">[RFC7636]</a></strong>) and, if supported, <strong>MUST</strong> use S256 as the code challenge method.</p></li>
+<li><p>Data Recipient Software Products <strong>SHOULD</strong> use Authorization Code Flow.</p></li>
 </ul>
 
 <p><a id="hybrid-flow"></a></p>
@@ -4659,8 +4654,7 @@ <h4 id='software-statement-assertion-ssa'>Software Statement Assertion (SSA)</h4
 <blockquote>
 <p>An SSA is a digitally signed JSON Web Token (JWT) created in accordance with <strong><a href="#nref-JWT">[JWT]</a></strong> that asserts metadata values about the client software.</p>
 </blockquote>
-<pre class="highlight diff tab-diff"><code>Replaced FAPI draft references with FAPI 1.0 Final references
-</code></pre>
+
 <p>Such that:</p>
 
 <ul>
@@ -4982,7 +4976,6 @@ <h3 id='registration-request-using-jwt'>Registration Request using JWT</h3>
 {
   "signature":...
 }
-</code></pre><pre class="highlight diff tab-diff"><code>Replaced FAPI draft references with FAPI 1.0 Final references
 </code></pre>
 <p>To register with a Data Holder, the Data Recipient sends an HTTP POST to the Data Holder registration endpoint.</p>
 
@@ -4993,8 +4986,7 @@ <h3 id='registration-request-using-jwt'>Registration Request using JWT</h3>
 </ul>
 
 <p>The client registration request <strong>MUST</strong> contain the following claims in the JWT payload unless designated as Optional:</p>
-<pre class="highlight diff tab-diff"><code>Replaced FAPI draft references with FAPI 1.0 Final references
-</code></pre>
+
 <table><thead>
 <tr>
 <th>Claim</th>
@@ -5122,8 +5114,7 @@ <h4 id='id-token-algorithm-selection-considerations'>ID Token Algorithm Selectio
 <p>Data Holders <strong>MUST</strong> support at a minimum, 1 algorithm for each claim.</p>
 
 <p>Data Recipients <strong>MUST</strong> support all the algorithms used in the ecosystem to ensure they can communicate with all Data Holders.</p>
-<pre class="highlight diff tab-diff"><code>Replaced FAPI draft references with FAPI 1.0 Final references
-</code></pre>
+
 <p>ID Token algorithm considerations remain relevant where the OIDC Hybrid Flow is leveraged as defined in the Consumer Data Standards and in accordance with sections <a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html#id-token-as-detached-signature">5.1.1</a>, <a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html#id-token-as-detached-signature-1">5.2.2.1</a>, and <a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html#id-token-as-detached-signature-2">5.2.3.1</a> of <strong><a href="#nref-FAPI-1-0-Advanced">[FAPI-1.0-Advanced]</a></strong>.</p>
 <h4 id='jarm-response-encryption-considerations'>JARM Response Encryption Considerations</h4>
 <p>If Data Holders support authorisation response encryption, they <strong>MUST</strong> support, at a minimum, one of each of the following <code>alg</code> and <code>enc</code> algorithms:</p>
@@ -5717,18 +5708,15 @@ <h2 id='tokens'>Tokens</h2><h3 id='id-token'>ID Token</h3>
 }
 </code></pre>
 <p>ID Tokens are specified in <a href="https://openid.net/specs/openid-connect-core-1_0.html#IDToken">section 2</a> of the <strong><a href="#nref-OIDC">[OIDC]</a></strong> standard.</p>
-<h4 id='baseline-id-token-requirements'>Baseline ID Token requirements</h4><pre class="highlight diff tab-diff"><code>Replaced FAPI draft references with FAPI 1.0 Final references
-</code></pre>
+<h4 id='baseline-id-token-requirements'>Baseline ID Token requirements</h4>
 <p>In addition to the mandatory claims specified in <a href="https://openid.net/specs/openid-connect-core-1_0.html#IDToken">section 2</a> of the <strong><a href="#nref-OIDC">[OIDC]</a></strong> standard, required claims for ID Tokens as part of Hybrid Flow authentication <strong>MUST</strong> align to <a href="https://openid.net/specs/openid-connect-core-1_0.html#HybridFlowAuth">section 3.3</a> (Authentication using the Hybrid Flow) of the <strong><a href="#nref-OIDC">[OIDC]</a></strong> standards and <a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html#authorization-server">section 5.2.2</a> and <a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html#authorization-response-parameter-injection-attack">section 8.4.3</a> of the <strong><a href="#nref-FAPI-1-0-Advanced">[FAPI-1.0-Advanced]</a></strong> profile.</p>
 
 <p>ID Tokens <strong>MUST</strong> be signed by Data Holders as specified in <a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html#algorithm-considerations">section 8.6</a> of <strong><a href="#nref-FAPI-1-0-Advanced">[FAPI-1.0-Advanced]</a></strong>.</p>
-<h4 id='oidc-hybrid-flow-requirements'>OIDC Hybrid Flow requirements</h4><pre class="highlight diff tab-diff"><code>Replaced FAPI draft references with FAPI 1.0 Final references
-</code></pre>
+<h4 id='oidc-hybrid-flow-requirements'>OIDC Hybrid Flow requirements</h4>
 <p>In accordance with <strong><a href="#nref-FAPI-1-0-Advanced">[FAPI-1.0-Advanced]</a></strong>, ID Tokens <strong>MUST</strong> be signed and encrypted when returned to a Data Recipient Software Product from both the Authorisation End Point and Token End Point.</p>
 
 <p>The ID Token returned from the Authorisation End Point <strong>MUST NOT</strong> contain any Personal Information (PI) claims.</p>
-<h5 id='hashing-value-for-state-and-authorisation-code'>Hashing value for state and authorisation code</h5><pre class="highlight diff tab-diff"><code>Replaced FAPI draft references with FAPI 1.0 Final references
-</code></pre>
+<h5 id='hashing-value-for-state-and-authorisation-code'>Hashing value for state and authorisation code</h5>
 <p>The following requirements apply to the OIDC Hybrid Flow:</p>
 
 <ul>
@@ -5743,8 +5731,7 @@ <h3 id='access-token'>Access Token</h3>
 <p>An Access Token <strong>MUST</strong> expire between <strong>2 minutes</strong> to <strong>10 minutes</strong> after the Data Holder issues it (at the discretion of the Data Holder).</p>
 
 <p>The process for refreshing an Access Token is described in <a href="https://openid.net/specs/openid-connect-core-1_0.html#RefreshingAccessToken">section 12.1</a> of <strong><a href="#nref-OIDC">[OIDC]</a></strong>.</p>
-<pre class="highlight diff tab-diff"><code>Removed legacy phasing requirements for FAPI 1.0 Final
-</code></pre>
+
 <ul>
 <li>Data Holders <strong>MUST</strong> reject token request with an authorization code (Section 1.3.1 of <strong><a href="#nref-RFC6749">[RFC6749]</a></strong>) if it has been previously used</li>
 </ul>
@@ -5756,8 +5743,7 @@ <h3 id='refresh-token'>Refresh Token</h3>
 <p>The expiration time for a Refresh Token <strong>MUST</strong> be set by the Data Holder.</p>
 
 <p>Refresh Token expiration <strong>MAY</strong> be any length of time greater than 28 days but <strong>MUST NOT</strong> exceed the end of the duration of sharing consented to by the Consumer.</p>
-<pre class="highlight diff tab-diff"><code>Removed legacy phasing requirements for FAPI 1.0 Final
-</code></pre>
+
 <ul>
 <li>  Data Holders <strong>MUST NOT</strong> cycle refresh tokens (rotation). In other words, Refresh Tokens <strong>SHOULD</strong> be issued with an &quot;exp&quot; equal to the sharing duration authorised by the Customer.</li>
 </ul>
@@ -5765,8 +5751,7 @@ <h3 id='token-expiry'>Token Expiry</h3>
 <p>The expiry time for issued access tokens and refresh tokens <strong>MUST</strong> be deterministic for the Data Recipient Software Product.</p>
 
 <p>In order to achieve this:</p>
-<pre class="highlight diff tab-diff"><code>Removed legacy phasing requirements for FAPI 1.0 Final
-</code></pre>
+
 <ul>
 <li>The Data Holder <strong>MUST</strong> indicate the lifetime in seconds of the access token in the <code>expires_in</code> field of the JSON object returned by the token end-point (see <a href="https://tools.ietf.org/html/rfc6749#section-4.2.2">section 4.2.2</a> of <strong><a href="#nref-OAUTH2">[OAUTH2]</a></strong>).</li>
 </ul>
@@ -5940,8 +5925,7 @@ <h3 id='holder-of-key-mechanism'>Holder of Key Mechanism</h3>
 <p>OAUTB SHALL NOT be supported due to a lack industry support.</p>
 
 <p><strong><a href="#nref-MTLS">[MTLS]</a></strong> HoK allows issued tokens to be bound to a client certificate as specified in <a href="https://tools.ietf.org/id/draft-ietf-oauth-mtls-07.html#SenderConstrainedAccess">section 3</a> of <strong><a href="#nref-MTLS">[MTLS]</a></strong>.</p>
-<h3 id='ciphers'>Ciphers</h3><pre class="highlight diff tab-diff"><code>Replaced FAPI draft RW references with FAPI 1.0 Final Advanced references. References pertain to the TLS considerations.
-</code></pre>
+<h3 id='ciphers'>Ciphers</h3>
 <p>Only the following cipher suites SHALL be permitted in accordance with <a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html#tls-considerations">section 8.5</a> of <strong><a href="#nref-FAPI-1-0-Advanced">[FAPI-1.0-Advanced]</a></strong>:</p>
 
 <ul>
@@ -6163,8 +6147,7 @@ <h2 id='request-object'>Request Object</h2>
 <p>Non-Normative Example - FAPI 1.0 Final Phase 3 Obligation  </p>
 </blockquote>
 
-<pre class="highlight diff tab-diff"><code><span class="gi">+ Added "response_mode" to the non normative example. This demonstrates the use of Authorization Code Flow in conjunction with JARM and FAPI 1.0
-</span></code></pre><pre class="highlight plaintext"><code>#Decoded Request Object JWT
+<pre class="highlight plaintext"><code>#Decoded Request Object JWT
 
 {
   "iss": "s6BhdRkqt3",
@@ -6196,7 +6179,6 @@ <h2 id='request-object'>Request Object</h2>
   "code_challenge": "ZTA2ZmFkYjUyMjA2NDNhZGVkYzE1M2I5OTYzZDAxNGI2NWNiZjAxMzVhNDlmMTk2NTlmZWE0OWVhOTQxZjhmZg==",
   "code_challenge_method": "S256"
 }
-</code></pre><pre class="highlight diff tab-diff"><code>Replaced FAPI draft references with FAPI 1.0 Final references
 </code></pre>
 
 <p>The Request Object is a signed and encoded JWT specified in <a href="https://openid.net/specs/openid-connect-core-1_0.html#RequestObject">section 6.1</a> of <strong>[OIDC]</strong>.  As per <strong><a href="#nref-FAPI-1-0-Advanced">[FAPI-1.0-Advanced]</a></strong> <a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html#authorization-server">section 5.2.2</a>, the <code>request</code> parameter <strong>MUST</strong> be present on requests to the <strong>[OIDC]</strong> Hybrid Authorisation End Point. The Request Object enables <strong>[OIDC]</strong> requests to be passed in a single and self-contained parameter.</p>
@@ -6249,9 +6231,6 @@ <h4 id='data-holders'>Data Holders</h4>
 
 <p>Data Holders <strong>MUST</strong> support Pushed Authorisation Requests (PAR) via the pushed authorisation end point according to <strong><a href="#nref-PAR">[PAR]</a></strong>.</p>
 
-<pre class="highlight diff tab-diff"><code>Removed legacy phasing requirements for FAPI 1.0 Final
-</code></pre>
-
 <ul>
 <li>Data Holders <strong>MUST</strong> support <strong><a href="#nref-RFC9126">[RFC9126]</a></strong> (PAR) using <strong><a href="#nref-PKCE">[PKCE]</a></strong> (<strong><a href="#nref-RFC7636">[RFC7636]</a></strong>) with S256 as the code challenge method in accordance with <strong><a href="#nref-FAPI-1-0-Advanced">[FAPI-1.0-Advanced]</a></strong> <a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html#authorization-server">section 5.2.2</a>.</li>
 <li>  Data Holders <strong>MUST</strong> require PAR for authorisation request data in accordance with <strong><a href="#nref-RFC9126">[RFC9126]</a></strong> where &quot;require_pushed_authorization_requests&quot; parameter is set to &quot;true&quot;.</li>
@@ -6261,8 +6240,8 @@ <h4 id='data-holders'>Data Holders</h4>
 <li>  Data Holders <strong>MUST</strong> reject the reuse of &quot;request_uri&quot; values.</li>
 </ul>
 
-<h4 id='data-recipient-software-products'>Data Recipient Software Products</h4><pre class="highlight diff tab-diff"><code>Removed legacy phasing requirements for FAPI 1.0 Final
-</code></pre>
+<h4 id='data-recipient-software-products'>Data Recipient Software Products</h4>
+
 <ul>
 <li>  Data Recipients Software Products <strong>MUST</strong> send request object containing a &quot;nbf&quot; claim and an &quot;exp&quot; claim that has a lifetime of no longer than 60 minutes after the &quot;nbf&quot; claim.</li>
 <li>Data Recipient Software Products <strong>MUST</strong> ONLY use a &quot;request_uri&quot; value once</li>
@@ -6271,14 +6250,14 @@ <h4 id='data-recipient-software-products'>Data Recipient Software Products</h4><
 </ul>
 
 <h2 id='security-endpoints'>Security Endpoints</h2>
+
 <h3 id='openid-provider-configuration-end-point'>OpenID Provider Configuration End Point</h3>
 
 <blockquote>
 <p>Non-Normative Example</p>
 </blockquote>
 
-<pre class="highlight diff tab-diff"><code><span class="gi">+ Adds examples for all metadata parameters required by the Data Standards and upstream normative references
-</span></code></pre><pre class="highlight plaintext"><code>## Request
+<pre class="highlight plaintext"><code>## Request
 
 GET /.well-known/openid-configuration HTTP/1.1
 Host: www.dh.com.au
@@ -6354,11 +6333,6 @@ <h3 id='openid-provider-configuration-end-point'>OpenID Provider Configuration E
 
 <p>This endpoint does not require <a href="https://consumerdatastandardsaustralia.github.io/standards/#cors">CORS</a>.</p>
 
-<pre class="highlight diff tab-diff"><code>Replaced FAPI draft references with FAPI 1.0 Final references
-
-<span class="gi">+ Adds all metadata parameters required by the Data Standards and upstream normative references
-</span></code></pre>
-
 <p>At a minimum, the Data Holder metadata <strong>MUST</strong> include:</p>
 
 <p><strong><a href="#nref-OIDD">[OIDD]</a></strong></p>
@@ -6370,11 +6344,11 @@ <h3 id='openid-provider-configuration-end-point'>OpenID Provider Configuration E
 <li><code>grant_types_supported</code>: The list of the OAuth 2.0 Grant Type values supported</li>
 <li><code>id_token_encryption_alg_values_supported</code>: The list of the supported JWE algorithms for securing the issued ID tokens. Must conform to <strong><a href="#nref-FAPI-RW-Draft">[FAPI-RW-Draft]</a></strong> and <strong><a href="#nref-OIDD">[OIDD]</a></strong>. Required for Data Holders supporting OIDC Hybrid Flow</li>
 <li><code>id_token_encryption_enc_values_supported</code>: The list of the supported JWE encryption methods for securing the issued ID tokens. Required for Data Holders supporting OIDC Hybrid Flow</li>
-<li><code>id_token_signing_alg_values_supported</code>: The list of the JWS signing algorithms (<code>alg</code> values) supported </li>
+<li><code>id_token_signing_alg_values_supported</code>: The list of the JWS signing algorithms (<code>alg</code> values) supported</li>
 <li><code>issuer</code>: URL that the Data Holder asserts as its Issuer Identifier</li>
 <li><code>jwks_uri</code>: The JSON Web Key Set for the data holder</li>
 <li><code>registration_endpoint</code>: URL of the Client Registration End Point</li>
-<li><code>request_object_signing_alg_values_supported</code>: The list of the JWS signing algorithms (<code>alg</code> values) supported for signing request objects. </li>
+<li><code>request_object_signing_alg_values_supported</code>: The list of the JWS signing algorithms (<code>alg</code> values) supported for signing request objects.</li>
 <li><code>response_modes_supported</code>: The list of the OAuth 2.0 <code>response_mode</code> values supported</li>
 <li><code>response_types_supported</code>: The list of the OAuth 2.0 <code>response_type</code> values supported</li>
 <li><code>scopes_supported</code>:  The list of supported scopes</li>
@@ -6523,9 +6497,6 @@ <h3 id='authorisation-end-point'>Authorisation End Point</h3>
 </tr>
 </tbody></table>
 
-<pre class="highlight diff tab-diff"><code>Replaced FAPI draft references with FAPI 1.0 Final references
-</code></pre>
-
 <p>The requirements for the Authorisation End Point are specified in <a href="https://openid.net/specs/openid-connect-core-1_0.html#HybridAuthorizationEndpoint">section 3.3.2</a> of <strong><a href="#nref-OIDC">[OIDC]</a></strong> and further specified under section <a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html#authorization-server">5.2.2</a> of <strong><a href="#nref-FAPI-1-0-Advanced">[FAPI-1.0-Advanced]</a></strong>.  This end point is invoked as part of the <a href="#hybrid-flow">Hybrid Authentication flow</a>.</p>
 
 <p>This endpoint does not require <a href="https://consumerdatastandardsaustralia.github.io/standards/#cors">CORS</a>.</p>
@@ -6897,24 +6868,27 @@ <h3 id='cdr-arrangement-revocation-end-point'>CDR Arrangement Revocation End Poi
 
 <p>Data Holder&#39;s MUST use the Data Recipient Software Product&#39;s CDR Arrangement Revocation End Point with a valid <code>cdr_arrangement_id</code> to notify the Data Recipient Software Product when consent is revoked by the consumer via the Data Holder.</p>
 
-<h3 id='pushed-authorisation-end-point'>Pushed Authorisation End Point</h3><pre class="highlight diff tab-diff"><code>Updated non-normtative example to use RFC9126, not the draft PAR specification
-</code></pre>
+<h3 id='pushed-authorisation-end-point'>Pushed Authorisation End Point</h3>
+
 <blockquote>
 <p>Non-Normative Example<br>
 Utilising RFC9126 and OIDC Hybrid Flow</p>
 
 <p>Request</p>
 </blockquote>
+
 <pre class="highlight plaintext"><code>POST /par HTTP/1.1
      Host: data.holder.com.au
      Content-Type: application/x-www-form-urlencoded
 
 request=eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjEyMyJ9.ey...
 </code></pre>
+
 <blockquote>
 <p>Decoded Request<br>
 This example shows an authorisation request using the OIDC Hybrid Flow</p>
 </blockquote>
+
 <pre class="highlight plaintext"><code>{
   "iss": "s6BhdRkqt3",
   "exp": 1516239322,
@@ -6942,9 +6916,11 @@ <h3 id='pushed-authorisation-end-point'>Pushed Authorisation End Point</h3><pre
   }
 }
 </code></pre>
+
 <blockquote>
 <p>Response</p>
 </blockquote>
+
 <pre class="highlight plaintext"><code>HTTP/1.1 201 Created
 Content-Type: application/json
 Cache-Control: no-cache, no-store
@@ -6953,9 +6929,11 @@ <h3 id='pushed-authorisation-end-point'>Pushed Authorisation End Point</h3><pre
   "expires_in": 3600
 }
 </code></pre>
+
 <blockquote>
 <p>Authorise</p>
 </blockquote>
+
 <pre class="highlight plaintext"><code>## The request_uri is used by the ADR in the subsequent authorisation request as follows
 ## (note this example is pre-RFC using Draft 01 of the PAR standard, hence it includes
 ## the mandatory oAuth parameters as per FAPI R/W for confidential clients must be
@@ -6968,24 +6946,27 @@ <h3 id='pushed-authorisation-end-point'>Pushed Authorisation End Point</h3><pre
 HTTP/1.1
 Host: data.holder.com.au
 </code></pre>
+
 <blockquote>
 <p>Non-Normative Example - FAPI 1.0 Final Phase 3 Obligations<br>
 Utilising FAPI 1.0 Final, PAR RFC9126, PKCE, JARM and Authorization Code Flow</p>
 
 <p>Request</p>
 </blockquote>
+
 <pre class="highlight plaintext"><code>POST /par HTTP/1.1
      Host: data.holder.com.au
      Content-Type: application/x-www-form-urlencoded
 
 request=eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjEyMyJ9.ey...
 </code></pre>
+
 <blockquote>
 <p>Decoded Request - FAPI 1.0 Final Phase 3 Obligation<br>
 This example shows an authorisation request using the Authorisation Code Flow (FAPI 1.0 migration Phase 3)</p>
 </blockquote>
-<pre class="highlight diff tab-diff"><code><span class="gi">+ Added "response_mode" to the non normative example. This demonstrates the use of Authorization Code Flow in conjunction with JARM and FAPI 1.0
-</span></code></pre><pre class="highlight plaintext"><code>{
+
+<pre class="highlight plaintext"><code>{
   "iss": "s6BhdRkqt3",
   "exp": 1680832800,
   "nbf": 1680829200,
@@ -7016,9 +6997,11 @@ <h3 id='pushed-authorisation-end-point'>Pushed Authorisation End Point</h3><pre
   "code_challenge_method": "S256"
 }
 </code></pre>
+
 <blockquote>
 <p>Response - FAPI 1.0 Final Phase 3 Obligation  </p>
 </blockquote>
+
 <pre class="highlight plaintext"><code>HTTP/1.1 201 Created
 Content-Type: application/json
 Cache-Control: no-cache, no-store
@@ -7027,9 +7010,11 @@ <h3 id='pushed-authorisation-end-point'>Pushed Authorisation End Point</h3><pre
   "expires_in": 3600
 }
 </code></pre>
+
 <blockquote>
 <p>Authorise - FAPI 1.0 Final Phase 3 Obligation  </p>
 </blockquote>
+
 <pre class="highlight plaintext"><code>## This is used by the ADR in the subsequent authorisation request as follows
 ## (this example uses PAR RFC 9126 and Authorization Code Flow):
 
@@ -7038,9 +7023,11 @@ <h3 id='pushed-authorisation-end-point'>Pushed Authorisation End Point</h3><pre
 HTTP/1.1
 Host: data.holder.com.au
 </code></pre>
+
 <blockquote>
 <p>Authorisation response using JARM response encryption - FAPI 1.0 Final Phase 3 Obligation  </p>
 </blockquote>
+
 <pre class="highlight plaintext"><code>eyJraWQiOiIwZWQ3YTNkZi1hMGJlLTRhZjQtOTk0YS1jNDBhODc0ODQwNjMiLCJhbGciOiJQUzI1NiJ9.eyJhdWQiOiIxMjM0NSIsImNvZGUiOiJpMVdzUm4xdUIxIiwiaXNzIjoiaHR0cHM6Ly9kYXRhLmhvbGRlci5jb20uYXUvIiwic3RhdGUiOiJhZjBpZmpzbGRraiIsImV4cCI6MTY2NzI2ODAwMH0.flBD3bTUHUFiNMbfgt-Uqt4wnEFHY79QYx0f9qrqPGPZLB-RBb-F20aPTyB9XaJ1JJ3ie1m0YxdMC7t6aiXSchZZQXBmYpIjvlbTceOVBYlr88llqeLAfQ5nCDD4p2axqyedpA83OgPF8i_Ngw0oRsCwBTueo6C40wYeI3ZT_n0hucQqGHcSoR1im7IY1rY0x99EZjJI3pxVtGwst6e-msomipnYedCdkNuPHE_Rnj0g897zi_NdK6m3dhxcpwaoMXcaYfMkkkzTlbz5_Ic9lWMx_z01C2wRNjRBArEJsNXW0Q8Vdhk_vtOAmO92Pr3cI8BpTr5KdY2O1iD-yRnkug
 
 ## Decoded Response
@@ -7056,6 +7043,7 @@ <h3 id='pushed-authorisation-end-point'>Pushed Authorisation End Point</h3><pre
   "exp": 1667268000
 }
 </code></pre>
+
 <table><thead>
 <tr>
 <th>Description</th>
@@ -7081,8 +7069,7 @@ <h3 id='pushed-authorisation-end-point'>Pushed Authorisation End Point</h3><pre
 </tbody></table>
 
 <p>Data Holders <strong>MUST</strong> support Pushed Authorisation Requests (PAR) via the pushed authorisation end point according to <strong><a href="#nref-PAR">[PAR]</a></strong>.</p>
-<pre class="highlight diff tab-diff"><code><span class="gd">- Removed legacy phasing requirements for FAPI 1.0 Final using PAR
-</span></code></pre>
+
 <p>Data Recipient Software Products <strong>MUST</strong> send authorisation requests using <strong><a href="#nref-PAR">[PAR]</a></strong> if supported by the Data Holder.</p>
 
 <p>The Data Holder response provides the Data Recipient Software Product with a Request URI in the response. The Request URI is then passed to the Data Holder’s Authorisation End Point to initiate an authorisation flow.</p>
@@ -8593,9 +8580,7 @@ <h3 id='base-urls'>Base URLs:</h3>
 <td>https://secure.api.cdr.gov.au</td>
 </tr>
 </tbody></table>
-<pre class="highlight diff tab-diff"><code>Amended the jwks and well known endpoint paths to reflect actual
-Register implementation
-</code></pre>
+
 <h2 id='get-openid-provider-config'>Get OpenId Provider Config</h2>
 
 <p><a id="opIdGetOpenIdProviderConfig"></a></p>
@@ -12487,11 +12472,6 @@ <h2 id='traffic-thresholds'>Traffic Thresholds</h2>
 
 <p>For Unattended traffic during high traffic periods only best effort support is required.</p>
 
-<pre class="highlight diff tab-diff"><code>Updated the static site wide TPS thresholds with a graduated set of
-thresholds depending on the number of active authorisations established
-with the data holder
-</code></pre>
-
 <p>For secure traffic (both Customer Present and Unattended) the following traffic thresholds will apply:</p>
 
 <ul>
@@ -12523,9 +12503,9 @@ <h2 id='data-recipient-requirements'>Data Recipient Requirements</h2>
 <li>Unattended calls should be managed to avoid short term bursts of traffic</li>
 </ul>
 
-<p><pre class="highlight diff tab-diff"><code><span class="gi">+ Added the Low Velocity Data Sets section
-</span></code></pre><h3 id='low-velocity-data-sets'>Low Velocity Data Sets</h3>
-<p>For endpoints that provide access to data that is low velocity (ie. the data does not change frequently) the Data Recipient Software Product is expected to cache the results of any data they receive and not request the same resource again until the data may reasonably have changed.</p></p>
+<h3 id='low-velocity-data-sets'>Low Velocity Data Sets</h3>
+
+<p>For endpoints that provide access to data that is low velocity (ie. the data does not change frequently) the Data Recipient Software Product is expected to cache the results of any data they receive and not request the same resource again until the data may reasonably have changed.</p>
 
 <p>For low velocity data sets, if the same data is requested repeatedly a Data Holder may reject subsequent requests for the same data during a specified period.</p>
 
@@ -12627,36 +12607,7 @@ <h1 id='banking-apis'>Banking APIs</h1>
 <tr><td><a href='./includes/swagger/cds_banking.json'>Banking OpenAPI Specification (JSON)</a></td></tr>
 <tr><td><a href='./includes/swagger/cds_banking.yaml'>Banking OpenAPI Specification (YAML)</a></td></tr>
 </table></p>
-<pre class="highlight diff tab-diff"><code>Updated the versions of the following APIs:
-<span class="gi">+ Get Scheduled Payments For Account from v1 to v2
-+ Get Scheduled Payments Bulk from v1 to v2
-+ Get Scheduled Payments For Specific Accounts from v1 to v2
-</span>
-
-Updated the following structures
-from:
-<span class="gd">- ResponseBankingScheduledPaymentsList
-- BankingScheduledPayment
-- BankingScheduledPaymentSet
-- BankingScheduledPaymentTo
-</span>
-to:
-<span class="gi">+ ResponseBankingScheduledPaymentsListV2
-+ BankingScheduledPaymentV2
-+ BankingScheduledPaymentSetV2
-+ BankingScheduledPaymentToV2
-</span>
-Added the following to 'BankingScheduledPaymentToV2' structure:
-<span class="gi">+ 'digitalWallet' ENUM value to the toUType field
-+ 'digitalWallet' object
-+ 'BankingDigitalWalletPayee' schema for 'digitalWallet' object
-</span>
-Replaced FAPI draft references with FAPI 1.0 Final references.
-References pertain to the x-fapi-auth-date header.
-
-Typo correction for the Get Products API description, changing
-"actual" to "actually"
-</code></pre>
+
 <h2 id='get-accounts'>Get Accounts</h2>
 
 <p><a id="opIdlistAccounts"></a></p>
@@ -25601,40 +25552,7 @@ <h1 id='energy-apis'>Energy APIs</h1>
 <tr><td><a href='./includes/swagger/cds_energy.json'>Energy OpenAPI Specification (JSON)</a></td></tr>
 <tr><td><a href='./includes/swagger/cds_energy.yaml'>Energy OpenAPI Specification (YAML)</a></td></tr>
 </table>
-<pre class="highlight diff tab-diff"><code>Updated description of EnergyPaymentSchedule.digitalWallet.name field
-from:
-<span class="gd">- The name assigned to the digital wallet by the owner of the wallet, else the display name provided by the digital wallet provider
-</span>to:
-<span class="gi">+ The display name of the wallet as given by the customer, else a default value defined by the data holder
-</span>
-Updated description of `EnergyPaymentSchedule.isTokenised` field to further clarify when it can be used
-
-Updated the versions of the following APIs:
-<span class="gi">+ Get Billing For Account from v1 to v2
-+ Get Bulk Billing from v1 to v2
-+ Get Billing For Specific Accounts from v1 to v2
-</span>
-Updated the following structures
-from:
-<span class="gd">- EnergyBillingListResponse
-- EnergyBillingTransaction
-- EnergyBillingDemandTransaction
-- EnergyBillingUsageTransaction
-</span>
-to:
-<span class="gi">+ EnergyBillingListResponseV2
-+ EnergyBillingTransactionV2
-+ EnergyBillingDemandTransactionV2
-+ EnergyBillingUsageTransactionV2
-</span>
-
-Added following ENUM values to EnergyBillingDemandTransaction.timeOfUseType field:
-<span class="gi">+ ALL_DAY
-+ EXCESS
-</span>
-Added following ENUM values to EnergyBillingUsageTransaction.timeOfUseType field:
-<span class="gi">+ ALL_DAY
-</span></code></pre>
+
 <h2 id='get-generic-plans'>Get Generic Plans</h2>
 
 <p><a id="opIdlistPlans"></a></p>
@@ -43515,9 +43433,7 @@ <h1 id='common-apis'>Common APIs</h1>
 <tr><td><a href='./includes/swagger/cds_common.json'>Common OpenAPI Specification (JSON)</a></td></tr>
 <tr><td><a href='./includes/swagger/cds_common.yaml'>Common OpenAPI Specification (YAML)</a></td></tr>
 </table></p>
-<pre class="highlight diff tab-diff"><code>Replaced FAPI draft references with FAPI 1.0 Final references.
-References pertain to the x-fapi-auth-date header.
-</code></pre>
+
 <h2 id='get-customer'>Get Customer</h2>
 
 <p><a id="opIdgetCustomer"></a></p>
@@ -46155,29 +46071,10 @@ <h1 id='admin-apis'>Admin APIs</h1>
 <tr><td><a href='./includes/swagger/cds_admin.json'>Admin OpenAPI Specification (JSON)</a></td></tr>
 <tr><td><a href='./includes/swagger/cds_admin.yaml'>Admin OpenAPI Specification (YAML)</a></td></tr>
 </table></p>
-<pre class="highlight diff tab-diff"><code><span class="gi">+ Adding v4 and v5 of the Get Metrics endpoint
-</span>
-v4 changes are:
-• Aligned types to standard CDR types
-• Separated availability and TPS metric into aggregated,
-  authenticated and unauthenticed
-• Error counts split by HTTP error code
-• Added new authorisation metrics
-• Added language to clarify that metrics are calculated at
-  the Data Holder brand level for Data Holders with multiple
-  brands
-
-v5 changes are:
-• Performance metrics broken down by performance tier
-• Include hourly metrics for performance metrics to align to NFRs
-• Inclusion of aggregate metric for performance metrics
-• Addition of abandonmentsByStage object to authorisation metrics
-
-Note that two typos were identified in the initial version of
-1.25.0 published on 8th July that have now been corrected. These
-are:
-• Incorrect description of the ErrorMetricsV2 model
-• Incorrect name of the preIdentification field
+<pre class="highlight diff tab-diff"><code>Modified the retirement date, and implementation requirements,
+for get Metrics v3
+
+Corrected the obligation date for Get Metrics v3
 </code></pre>
 <h2 id='metadata-update'>Metadata Update</h2>
 
@@ -46384,15 +46281,15 @@ <h2 id='get-metrics'>Get Metrics</h2>
 
 <p>This end point is not required to be implemented by the Australian Energy Market Operator, the Australian Energy Regulator or the Department of State administered by the Minister of Victoria administering the National Electricity (Victoria) Act 2005 (Vic).</p>
 
-<p>NOTE: This version must be implemented by <strong>June 13th 2024</strong></p>
+<p>NOTE: This version <strong>MUST</strong> be implemented by <strong>May 13th 2024</strong></p>
 
 <p>Obsolete versions: <a href="includes/obsolete/get-metrics-v1.html">v1</a> <a href="includes/obsolete/get-metrics-v2.html">v2</a>.</p>
 
 <p>Deprecated versions:</p>
 
 <ul>
-<li><a href="includes/obsolete/get-metrics-v3.html">v3</a></li>
-<li><a href="includes/obsolete/get-metrics-v4.html">v4</a> - This version, or v5, must be implemented by <strong>November 1st 2023</strong></li>
+<li><a href="includes/obsolete/get-metrics-v3.html">v3</a> - Implementation not required for Data Holders going live on, or after, 1st November 2023.  Other Data Holders <strong>MAY</strong> retire this version from the earlier of <strong>13th May 2023</strong> or from the time ACCC announce that they no longer call this version</li>
+<li><a href="includes/obsolete/get-metrics-v4.html">v4</a> - This version, or v5, <strong>MUST</strong> be implemented by <strong>November 1st 2023</strong></li>
 </ul>
 
 <p>If the Data Holder supports private_key_jwt client authentication they MUST validate the scope.</p>
@@ -53954,7 +53851,9 @@ <h2 id='experimental-standards'>Experimental Standards</h2>
 <h1 style="display:none"></h1>
 <h1 id='known-issues'>Known Issues</h1>
 <p>There are certain aspects of the standards that are actively under review. These known issues are articulated in the following table.</p>
-
+<pre class="highlight diff tab-diff"><code>The known issue related to the incorrect obligation date for
+Get Metrics v5 has been removed as it has been resolved
+</code></pre>
 <table><thead>
 <tr>
 <th style="text-align: left">Issue</th>
@@ -53962,10 +53861,6 @@ <h1 id='known-issues'>Known Issues</h1>
 </tr>
 </thead><tbody>
 <tr>
-<td style="text-align: left">Incorrect obligation date for Get Metrics v5</td>
-<td style="text-align: left">The future dated obligation date has been incorrectly documented in the standards as June 13th 2024.  This was a documentation error when v1.25.0 of the standards were published.  According to the decision of the Data Standards Chair (Decision 288) the obligation date for the implementation of Get Metrics v5 is <strong>May 13th 2024</strong>.  This will be corrected in the next release of the standards.</td>
-</tr>
-<tr>
 <td style="text-align: left">Register APIs use local version of common definitions</td>
 <td style="text-align: left">The Register APIs use a locally defined version of common schema definitions such as <code>ResponseErrorList</code> for error responses. These need to be updated to reference common swagger specifications inherited by the Common Swagger spec.</td>
 </tr>
@@ -54033,6 +53928,12 @@ <h1 id='change-log'>Change Log</h1>
 </tr>
 </thead><tbody>
 <tr>
+<td>23/08/2023</td>
+<td>1.26.0</td>
+<td>Changes to obligations for the implementation of Get Metrics</td>
+<td>See <a href="includes/releasenotes/releasenotes.1.26.0.html">release notes</a> and <a href="https://github.com/ConsumerDataStandardsAustralia/standards/issues/322">Decision 322</a> for details.</td>
+</tr>
+<tr>
 <td>08/07/2023</td>
 <td>1.25.0</td>
 <td>Changes arising from Decision 303 (Maintenance iteration 15) and Decision 288 (Metrics and NFRs)</td>
@@ -54488,6 +54389,11 @@ <h1 id='archives'>Archives</h1>
 </tr>
 </thead><tbody>
 <tr>
+<td><a href='https://consumerdatastandardsaustralia.github.io/standards-archives/standards-1.25.0/'>08/07/2023</a></td>
+<td>1.25.0</td>
+<td><a href='https://consumerdatastandardsaustralia.github.io/standards-archives/standards-1.25.0/'>Changes arising from Decision 303 (Maintenance iteration 15) and Decision 288 (Metrics and NFRs)</a></td>
+</tr>
+<tr>
 <td><a href='https://consumerdatastandardsaustralia.github.io/standards-archives/standards-1.24.0/'>07/05/2023</a></td>
 <td>1.24.0</td>
 <td><a href='https://consumerdatastandardsaustralia.github.io/standards-archives/standards-1.24.0/'>Changes arising from Decision 281 (Maintenance iteration 14)</a></td>
diff --git a/slate/source/includes/_admin.md.erb b/slate/source/includes/_admin.md.erb
index 6f34c9de..96650b37 100644
--- a/slate/source/includes/_admin.md.erb
+++ b/slate/source/includes/_admin.md.erb
@@ -10,29 +10,10 @@ This provides an overview of CDS Administration Endpoints. Please note this API
 </table>
 
 ```diff
-+ Adding v4 and v5 of the Get Metrics endpoint
+Modified the retirement date, and implementation requirements,
+for get Metrics v3
 
-v4 changes are:
-• Aligned types to standard CDR types
-• Separated availability and TPS metric into aggregated,
-  authenticated and unauthenticed
-• Error counts split by HTTP error code
-• Added new authorisation metrics
-• Added language to clarify that metrics are calculated at
-  the Data Holder brand level for Data Holders with multiple
-  brands
-
-v5 changes are:
-• Performance metrics broken down by performance tier
-• Include hourly metrics for performance metrics to align to NFRs
-• Inclusion of aggregate metric for performance metrics
-• Addition of abandonmentsByStage object to authorisation metrics
-
-Note that two typos were identified in the initial version of
-1.25.0 published on 8th July that have now been corrected. These
-are:
-• Incorrect description of the ErrorMetricsV2 model
-• Incorrect name of the preIdentification field
+Corrected the obligation date for Get Metrics v3
 ```
 
 <%= partial "includes/cds_admin.md" %>
diff --git a/slate/source/includes/_banking_apis.md.erb b/slate/source/includes/_banking_apis.md.erb
index d0593887..6ffeea82 100644
--- a/slate/source/includes/_banking_apis.md.erb
+++ b/slate/source/includes/_banking_apis.md.erb
@@ -10,38 +10,6 @@ This specification defines the APIs for Data Holders exposing Banking endpoints.
 <tr><td><a href='./includes/swagger/cds_banking.yaml'>Banking OpenAPI Specification (YAML)</a></td></tr>
 </table>
 
-```diff
-Updated the versions of the following APIs:
-+ Get Scheduled Payments For Account from v1 to v2
-+ Get Scheduled Payments Bulk from v1 to v2
-+ Get Scheduled Payments For Specific Accounts from v1 to v2
-
-
-Updated the following structures
-from:
-- ResponseBankingScheduledPaymentsList
-- BankingScheduledPayment
-- BankingScheduledPaymentSet
-- BankingScheduledPaymentTo
-
-to:
-+ ResponseBankingScheduledPaymentsListV2
-+ BankingScheduledPaymentV2
-+ BankingScheduledPaymentSetV2
-+ BankingScheduledPaymentToV2
-
-Added the following to 'BankingScheduledPaymentToV2' structure:
-+ 'digitalWallet' ENUM value to the toUType field
-+ 'digitalWallet' object
-+ 'BankingDigitalWalletPayee' schema for 'digitalWallet' object
-
-Replaced FAPI draft references with FAPI 1.0 Final references.
-References pertain to the x-fapi-auth-date header.
-
-Typo correction for the Get Products API description, changing
-"actual" to "actually"
-```
-
 <%= partial "includes/cds_banking.md" %>
 <%= partial "includes/banking/_product_categories.md" %>
 <%= partial "includes/banking/_product_components.md" %>
diff --git a/slate/source/includes/_common_apis.md.erb b/slate/source/includes/_common_apis.md.erb
index 563569ad..3ec560c3 100644
--- a/slate/source/includes/_common_apis.md.erb
+++ b/slate/source/includes/_common_apis.md.erb
@@ -8,8 +8,4 @@ This specification defines the Common APIs that apply to Data Holders multiple s
 <tr><td><a href='./includes/swagger/cds_common.yaml'>Common OpenAPI Specification (YAML)</a></td></tr>
 </table>
 
-```diff
-Replaced FAPI draft references with FAPI 1.0 Final references.
-References pertain to the x-fapi-auth-date header.
-```
 <%= partial "includes/cds_common.md" %>
diff --git a/slate/source/includes/_energy_apis.md.erb b/slate/source/includes/_energy_apis.md.erb
index eac47e30..223aa56a 100644
--- a/slate/source/includes/_energy_apis.md.erb
+++ b/slate/source/includes/_energy_apis.md.erb
@@ -8,40 +8,4 @@ This specification defines the APIs for Data Holders exposing Energy endpoints.
 <tr><td><a href='./includes/swagger/cds_energy.yaml'>Energy OpenAPI Specification (YAML)</a></td></tr>
 </table>
 
-```diff
-Updated description of EnergyPaymentSchedule.digitalWallet.name field
-from:
-- The name assigned to the digital wallet by the owner of the wallet, else the display name provided by the digital wallet provider
-to:
-+ The display name of the wallet as given by the customer, else a default value defined by the data holder
-
-Updated description of `EnergyPaymentSchedule.isTokenised` field to further clarify when it can be used
-
-Updated the versions of the following APIs:
-+ Get Billing For Account from v1 to v2
-+ Get Bulk Billing from v1 to v2
-+ Get Billing For Specific Accounts from v1 to v2
-
-Updated the following structures
-from:
-- EnergyBillingListResponse
-- EnergyBillingTransaction
-- EnergyBillingDemandTransaction
-- EnergyBillingUsageTransaction
-
-to:
-+ EnergyBillingListResponseV2
-+ EnergyBillingTransactionV2
-+ EnergyBillingDemandTransactionV2
-+ EnergyBillingUsageTransactionV2
-
-
-Added following ENUM values to EnergyBillingDemandTransaction.timeOfUseType field:
-+ ALL_DAY
-+ EXCESS
-
-Added following ENUM values to EnergyBillingUsageTransaction.timeOfUseType field:
-+ ALL_DAY
-```
-
 <%= partial "includes/cds_energy.md" %>
diff --git a/slate/source/includes/_register.md.erb b/slate/source/includes/_register.md.erb
index 49879b52..e2f8f7c4 100644
--- a/slate/source/includes/_register.md.erb
+++ b/slate/source/includes/_register.md.erb
@@ -38,9 +38,4 @@ These endpoints are exposed by the Register and consumed by Data Holders and Dat
 |**Production TLS**|https://api.cdr.gov.au|
 |**Production mTLS**|https://secure.api.cdr.gov.au|
 
-```diff
-Amended the jwks and well known endpoint paths to reflect actual
-Register implementation
-```
-
 <%= partial "includes/cds_register.md" %>
diff --git a/slate/source/includes/additional/candidates/telco_apis.md b/slate/source/includes/additional/candidates/telco_apis.md
index 364daf31..aefb3fe5 100644
--- a/slate/source/includes/additional/candidates/telco_apis.md
+++ b/slate/source/includes/additional/candidates/telco_apis.md
@@ -4,14 +4,3 @@ This specification defines the APIs for Data Holders exposing Telecommunications
 <tr><td><a href='../../../includes/swagger/cds_telco.json'>Telco OpenAPI Specification (JSON)</a></td></tr>
 <tr><td><a href='../../../includes/swagger/cds_telco.yaml'>Telco OpenAPI Specification (YAML)</a></td></tr>
 </table>
-
-```diff
-Updated description of TelcoPaymentScheduleDigitalWallet.name field
-from:
-- The name assigned to the digital wallet by the owner of the wallet, else the display name provided by the digital wallet provider
-to:
-+ The display name of the wallet as given by the customer, else a default value defined by the data holder
-
-Replaced FAPI draft references with FAPI 1.0 Final references.
-References pertain to the x-fapi-auth-date header.
-```
diff --git a/slate/source/includes/archives.md b/slate/source/includes/archives.md
index 529e3389..3a6a76cc 100644
--- a/slate/source/includes/archives.md
+++ b/slate/source/includes/archives.md
@@ -4,6 +4,7 @@ The following table lists archived versions of the Consumer Data Standards.  The
 
 |Releases Date|Version|Description|
 |-------------|-------|-----------|
+|<a href='https://consumerdatastandardsaustralia.github.io/standards-archives/standards-1.25.0/'>08/07/2023</a>|1.25.0|<a href='https://consumerdatastandardsaustralia.github.io/standards-archives/standards-1.25.0/'>Changes arising from Decision 303 (Maintenance iteration 15) and Decision 288 (Metrics and NFRs)</a>|
 |<a href='https://consumerdatastandardsaustralia.github.io/standards-archives/standards-1.24.0/'>07/05/2023</a>|1.24.0|<a href='https://consumerdatastandardsaustralia.github.io/standards-archives/standards-1.24.0/'>Changes arising from Decision 281 (Maintenance iteration 14)</a>|
 |<a href='https://consumerdatastandardsaustralia.github.io/standards-archives/standards-1.23.0/'>24/04/2023</a>|1.23.0|<a href='https://consumerdatastandardsaustralia.github.io/standards-archives/standards-1.23.0/'>Changes arising from Decision Proposal 298</a>|
 |<a href='https://consumerdatastandardsaustralia.github.io/standards-archives/standards-1.22.1/'>22/03/2023</a>|1.22.1|<a href='https://consumerdatastandardsaustralia.github.io/standards-archives/standards-1.22.1/'>Patch release including updates to draft Telco standards</a>|
diff --git a/slate/source/includes/cds_admin.md b/slate/source/includes/cds_admin.md
index eea960a2..adf6ae4a 100644
--- a/slate/source/includes/cds_admin.md
+++ b/slate/source/includes/cds_admin.md
@@ -145,14 +145,14 @@ This end point allows the ACCC to obtain operational statistics from the Data Ho
 
 This end point is not required to be implemented by the Australian Energy Market Operator, the Australian Energy Regulator or the Department of State administered by the Minister of Victoria administering the National Electricity (Victoria) Act 2005 (Vic).
 
-NOTE: This version must be implemented by **June 13th 2024**
+NOTE: This version **MUST** be implemented by **May 13th 2024**
 
 Obsolete versions: [v1](includes/obsolete/get-metrics-v1.html) [v2](includes/obsolete/get-metrics-v2.html).
 
 Deprecated versions:
 
-- [v3](includes/obsolete/get-metrics-v3.html)
-- [v4](includes/obsolete/get-metrics-v4.html) - This version, or v5, must be implemented by **November 1st 2023**
+- [v3](includes/obsolete/get-metrics-v3.html) - Implementation not required for Data Holders going live on, or after, 1st November 2023.  Other Data Holders **MAY** retire this version from the earlier of **13th May 2023** or from the time ACCC announce that they no longer call this version
+- [v4](includes/obsolete/get-metrics-v4.html) - This version, or v5, **MUST** be implemented by **November 1st 2023**
 
 If the Data Holder supports private_key_jwt client authentication they MUST validate the scope.
 
diff --git a/slate/source/includes/changelog.md b/slate/source/includes/changelog.md
index b57070fa..4d5f5f62 100644
--- a/slate/source/includes/changelog.md
+++ b/slate/source/includes/changelog.md
@@ -4,6 +4,7 @@ The following table lists the changes made to these standards in reverse date or
 
 |Change Date|Version|Description|Detail Of change|
 |-----------|-------|-----------|----------------|
+|23/08/2023| 1.26.0 | Changes to obligations for the implementation of Get Metrics | See [release notes](includes/releasenotes/releasenotes.1.26.0.html) and [Decision 322](https://github.com/ConsumerDataStandardsAustralia/standards/issues/322) for details. |
 |08/07/2023| 1.25.0 | Changes arising from Decision 303 (Maintenance iteration 15) and Decision 288 (Metrics and NFRs) | See [release notes](includes/releasenotes/releasenotes.1.25.0.html), [Decision 303](https://github.com/ConsumerDataStandardsAustralia/standards/issues/303) and [Decision 288](https://github.com/ConsumerDataStandardsAustralia/standards/issues/288) for details. |
 |07/05/2023| 1.24.0 | Changes arising from Decision 281 (Maintenance iteration 14) | See [release notes](includes/releasenotes/releasenotes.1.24.0.html) and [Decision 281](https://github.com/ConsumerDataStandardsAustralia/standards/issues/281) for details. |
 |14/04/2023| 1.23.0 | Changes arising from Decision Proposal 298 | See [release notes](includes/releasenotes/releasenotes.1.23.0.html) and [Decision 298](https://github.com/ConsumerDataStandardsAustralia/standards/issues/298) for details. |
diff --git a/slate/source/includes/endpoint-version-schedule/includes/_common-dh.md b/slate/source/includes/endpoint-version-schedule/includes/_common-dh.md
index 97d52cd6..d1bd92ac 100644
--- a/slate/source/includes/endpoint-version-schedule/includes/_common-dh.md
+++ b/slate/source/includes/endpoint-version-schedule/includes/_common-dh.md
@@ -23,6 +23,11 @@
 | Admin APIs      | Metadata Update                              | ``/admin/register/metadata``                                   | <span class="method post">POST</span>  | V1      | 2020-07-01          | N/A             | 2019-09-30, V1.0.0  | N/A                |
 | Admin APIs      | Get Metrics                                  | ``/admin/metrics``                                             | <span class="method get">GET</span>    | V1      | 2020-07-01          | 2021-10-31      | 2019-09-30, V1.0.0  | 2021-04-29, V1.9.0 |
 | Admin APIs      | Get Metrics                                  | ``/admin/metrics``                                             | <span class="method get">GET</span>    | V2      | 2021-07-31          | 2022-12-05      | 2020-09-16, V1.5.0  | 2021-10-06, V1.12.0                |
-| Admin APIs      | Get Metrics                                  | ``/admin/metrics``                                             | <span class="method get">GET</span>    | V3      | 2022-10-01          | N/A             | 2021-10-06, V1.12.0 | N/A                |
-| Admin APIs      | Get Metrics                                  | ``/admin/metrics``                                             | <span class="method get">GET</span>    | V4      | 2023-11-01          | When v5 Implemented | 2023-07-08, V1.25.0 | N/A                |
-| Admin APIs      | Get Metrics                                  | ``/admin/metrics``                                             | <span class="method get">GET</span>    | V5      | 2024-06-13          | N/A | 2023-07-08, V1.25.0 | N/A                |
+| Admin APIs      | Get Metrics                                  | ``/admin/metrics``                                             | <span class="method get">GET</span>    | V3      | 2022-10-01          | 2024-05-13 **&dagger;** | 2021-10-06, V1.12.0 | 2023-07-08, V1.25.0 |
+| Admin APIs      | Get Metrics                                  | ``/admin/metrics``                                             | <span class="method get">GET</span>    | V4      | 2023-11-01          | When v5 Implemented | 2023-07-08, V1.25.0 | 2023-07-08, V1.25.0 |
+| Admin APIs      | Get Metrics                                  | ``/admin/metrics``                                             | <span class="method get">GET</span>    | V5      | 2024-05-13          | N/A | 2023-07-08, V1.25.0 | N/A                |
+
+**&dagger;NOTE:** the details of the retirement date for Get Metrics v3 is as follows:
+
+* Implementation of Get Metrics v3 is not required for Data Holders going live on, or after, 1st November 2023
+* Other Data Holders **MAY** retire this version from the earlier of **13th May 2023** or from the time ACCC announce that they no longer call this version
diff --git a/slate/source/includes/introduction/_dependencies_schedule.md b/slate/source/includes/introduction/_dependencies_schedule.md
index 0f34bdbf..8203c6da 100644
--- a/slate/source/includes/introduction/_dependencies_schedule.md
+++ b/slate/source/includes/introduction/_dependencies_schedule.md
@@ -1,10 +1,5 @@
 ## Register Implementation Schedule
 
-```diff
-Removed the dependency schedule content for the Register APIs
-and linked to the ACCC implementation schedule.
-```
-
 The implementation of the Register APIs is managed by the ACCC.
 
 Their implementation schedule is [published here](https://consumerdataright.atlassian.net/wiki/spaces/DP/pages/30081043/Delivery+Dates).
diff --git a/slate/source/includes/introduction/_fdo.md b/slate/source/includes/introduction/_fdo.md
index 73062a98..1284e3cd 100644
--- a/slate/source/includes/introduction/_fdo.md
+++ b/slate/source/includes/introduction/_fdo.md
@@ -5,17 +5,19 @@ The standards, as published from time to time, may include specific statements i
 The table below highlights these areas of the standards.
 
 ```diff
-Removed legacy obligation dates more than 6 months in the past
-Fixed spelling of "Register"
+Added the retirement details for Get Metrics v3
 
-Added FDOs for decision 288 and 303
+Corrected the obligation date for Get Metrics v5
+
+Replaced the term `obsolete` with `retire` to clarify the
+intent of these statements
 ```
 
 |Section|Description|Applicable Date|
 |-------|-----------|---------------|
-|[Get Account Detail V1](#get-account-detail)|Data holders **MAY** obsolete version 1 of this end point from February 28th 2023.  Data recipients **MUST** upgrade their implementations to use version 2 by this time|February 28th 2023|
-|[Get Product Detail V3](#get-product-detail)|Data holders **MAY** obsolete version 3 of this end point from February 28th 2023.  Data recipients **MUST** upgrade their implementations to use version 4 by this time|February 28th 2023|
-|[Get Customer Detail V1](#get-customer-detail)|Data holders **MAY** obsolete version 1 of this end point from February 28th 2023.  Data recipients **MUST** upgrade their implementations to use version 2 by this time|February 28th 2023|
+|[Get Account Detail V1](#get-account-detail)|Data holders **MAY** retire version 1 of this end point from February 28th 2023.  Data recipients **MUST** upgrade their implementations to use version 2 by this time|February 28th 2023|
+|[Get Product Detail V3](#get-product-detail)|Data holders **MAY** retire version 3 of this end point from February 28th 2023.  Data recipients **MUST** upgrade their implementations to use version 4 by this time|February 28th 2023|
+|[Get Customer Detail V1](#get-customer-detail)|Data holders **MAY** retire version 1 of this end point from February 28th 2023.  Data recipients **MUST** upgrade their implementations to use version 2 by this time|February 28th 2023|
 |[Get Energy Accounts V2](#get-energy-accounts)|Data Holders **MUST** implement v2 of this endpoint by **April 14th 2023** | April 14th 2023 |
 |[Get Energy Account Detail V2](#get-energy-account-detail)|Data Holders **MUST** implement v2 of this endpoint by **April 14th 2023** | April 14th 2023 |
 |[Information Security profile](#security-profile) | FAPI 1.0 adoption is introduced across four phases.<br/><strong>Phase 3: Support Authorization Code Flow and Hybrid Flow</strong> includes, amongst other changes:<ul><li>Data Holders **MUST** support Authorization Code Flow</li><li>Data Holders **MUST** support Hybrid Flow</li></ul> | April 14th 2023 |
@@ -23,16 +25,17 @@ Added FDOs for decision 288 and 303
 |[Information Security profile](#security-profile) | FAPI 1.0 adoption is introduced across four phases.<br/><strong>Phase 4: Retire Hybrid Flow</strong>:<ul><li>Data Holders **MAY** retire Hybrid Flow</li></ul> | July 10th 2023 |
 |[Get Accounts V2](#get-accounts)|Version 2 of this end point **MUST** be made available by affected data holders by July 10th 2023|July 10th 2023|
 |[Get Account Detail V3](#get-account-detail)|Version 3 of this end point **MUST** be made available by affected data holders by July 10th 2023|July 10th 2023|
-|[Get Generic Plan Detail V2](#get-generic-plan-detail)|<ul><li>Data Holders **MUST** implement v2 of this endpoint by **November 1st 2023**</li><li>Data Holders **MAY** obsolete v1 of this endpoint from **September 9th 2024**</li></ul> | November 1st 2023 |
-|[Get Energy Account Detail V3](#get-account-detail)|<ul><li>Data Holders **MUST** implement v3 of this endpoint by **November 1st 2023**</li><li>Data Holders **MAY** obsolete v2 of this endpoint from **September 9th 2024**</li></ul>| November 1st 2023 |
-|[Get Billing For Account V2](#get-billing-for-account)|<ul><li>Data Holders **MUST** implement v2 of this endpoint by **November 1st 2023**</li><li>Data Holders **MAY** obsolete v1 of this endpoint from **September 9th 2024**</li></ul>| November 1st 2023 |
-|[Get Bulk Billing V2](#get-bulk-billing)|<ul><li>Data Holders **MUST** implement v2 of this endpoint by **November 1st 2023**</li><li>Data Holders **MAY** obsolete v1 of this endpoint from **September 9th 2024**</li></ul>| November 1st 2023 |
-|[Get Billing For Specific Accounts V2](#get-billing-for-specific-accounts)|<ul><li>Data Holders **MUST** implement v2 of this endpoint by **November 1st 2023**</li><li>Data Holders **MAY** obsolete v1 of this endpoint from **September 9th 2024**</li></ul>| November 1st 2023 |
-|[Get Metrics V4](#get-metrics)|<ul><li>Data Holders **MUST** implement v4 or V5 of this endpoint by **November 1st 2023**</li><li>Data Holders **MAY** deprecate v4 of this endpoint once V5 is implemented**</li></ul>| November 1st 2023 |
+|[Get Generic Plan Detail V2](#get-generic-plan-detail)|<ul><li>Data Holders **MUST** implement v2 of this endpoint by **November 1st 2023**</li><li>Data Holders **MAY** retire v1 of this endpoint from **September 9th 2024**</li></ul> | November 1st 2023 |
+|[Get Energy Account Detail V3](#get-account-detail)|<ul><li>Data Holders **MUST** implement v3 of this endpoint by **November 1st 2023**</li><li>Data Holders **MAY** retire v2 of this endpoint from **September 9th 2024**</li></ul>| November 1st 2023 |
+|[Get Billing For Account V2](#get-billing-for-account)|<ul><li>Data Holders **MUST** implement v2 of this endpoint by **November 1st 2023**</li><li>Data Holders **MAY** retire v1 of this endpoint from **September 9th 2024**</li></ul>| November 1st 2023 |
+|[Get Bulk Billing V2](#get-bulk-billing)|<ul><li>Data Holders **MUST** implement v2 of this endpoint by **November 1st 2023**</li><li>Data Holders **MAY** retire v1 of this endpoint from **September 9th 2024**</li></ul>| November 1st 2023 |
+|[Get Billing For Specific Accounts V2](#get-billing-for-specific-accounts)|<ul><li>Data Holders **MUST** implement v2 of this endpoint by **November 1st 2023**</li><li>Data Holders **MAY** retire v1 of this endpoint from **September 9th 2024**</li></ul>| November 1st 2023 |
+|[Get Metrics V4](#get-metrics)|<ul><li>Data Holders **MUST** implement v4 or V5 of this endpoint by **November 1st 2023**</li><li>Data Holders **MAY** retire v4 of this endpoint once V5 is implemented</li></ul>| November 1st 2023 |
 |[Private Key JWT Client Authentication](https://consumerdatastandardsaustralia.github.io/standards/?examples#client-authentication) | Change to support [**[RFC7521]**](#nref-RFC7521) such that, until November 13th 2023, clients authenticating using Private Key JWT are _recommended_ to provide the `client_id`, but no longer required. From November 13th 2023, it is then _optional_ to provide the `client_id`. This applies to ADRs and the CDR Register authenticating with Data Holders and ADRs authenticating with the CDR Register. | November 13th 2023 |
 |[Get Accounts V1](#get-account-detail)|Data Holders **MAY** decommission v1 of this end point from March 11th 2024| March 11th 2024 |
 |[Get Account Detail V2](#get-account-detail)|Data Holders **MAY** decommission v2 of this end point from March 11th 2024| March 11th 2024 |
-|[Get Scheduled Payments for Account V2](#get-scheduled-payments-for-account)|<ul><li>Data Holders **MUST** implement v2 of this endpoint by **March 11th 2024**</li><li>Data Holders **MAY** obsolete v1 of this endpoint from **September 9th 2024**</li></ul> | March 11th 2024 |
-|[Get Scheduled Payments Bulk V2](#get-scheduled-payments-bulk)|<ul><li>Data Holders **MUST** implement v2 of this endpoint by **March 11th 2024**</li><li>Data Holders **MAY** obsolete v1 of this endpoint from **September 9th 2024**</li></ul> | March 11th 2024 |
-|[Get Scheduled Payments For Specific Accounts V2](#get-scheduled-payments-for-specific-accounts)|<ul><li>Data Holders **MUST** implement v2 of this endpoint by **March 11th 2024**</li><li>Data Holders **MAY** obsolete v1 of this endpoint from **September 9th 2024**</li></ul> | March 11th 2024 |
-|[Get Metrics V5](#get-metrics)|<ul><li>Data Holders **MUST** implement V5 of this endpoint by **June 13th 2024**</li><li>Data Holders **MAY** deprecate v4 of this endpoint once V5 is implemented**</li></ul>| June 13th 2024 |
+|[Get Scheduled Payments for Account V2](#get-scheduled-payments-for-account)|<ul><li>Data Holders **MUST** implement v2 of this endpoint by **March 11th 2024**</li><li>Data Holders **MAY** retire v1 of this endpoint from **September 9th 2024**</li></ul> | March 11th 2024 |
+|[Get Scheduled Payments Bulk V2](#get-scheduled-payments-bulk)|<ul><li>Data Holders **MUST** implement v2 of this endpoint by **March 11th 2024**</li><li>Data Holders **MAY** retire v1 of this endpoint from **September 9th 2024**</li></ul> | March 11th 2024 |
+|[Get Scheduled Payments For Specific Accounts V2](#get-scheduled-payments-for-specific-accounts)|<ul><li>Data Holders **MUST** implement v2 of this endpoint by **March 11th 2024**</li><li>Data Holders **MAY** retire v1 of this endpoint from **September 9th 2024**</li></ul> | March 11th 2024 |
+|[Get Metrics V3](#get-metrics)|<ul><li>Data Holders **MAY** retire v3 of this endpoint by the earlier of **13th May 2024** or when the ACCC announce that this version is no longer being called</li><li>Data Holders going live on, or after, 1st November 2023 are not required to support this version</li></ul>| May 13th 2024 |
+|[Get Metrics V5](#get-metrics)|<ul><li>Data Holders **MUST** implement v5 of this endpoint by **May 13th 2024**</li><li>Data Holders **MAY** deprecate v4 of this endpoint once V5 is implemented</li></ul>| May 13th 2024 |
diff --git a/slate/source/includes/introduction/_intro.md b/slate/source/includes/introduction/_intro.md
index 63c76a2e..721caf3c 100644
--- a/slate/source/includes/introduction/_intro.md
+++ b/slate/source/includes/introduction/_intro.md
@@ -24,7 +24,7 @@ Some of these standards will be binding data standards under the Competition and
 
 ## Version
 
-These standards represent version 1.25.0 of the high level standards.  See the [versioning section](#versioning) for more information on how versions are managed in the standard.
+These standards represent version 1.26.0 of the high level standards.  See the [versioning section](#versioning) for more information on how versions are managed in the standard.
 
 ## Interpretation
 
diff --git a/slate/source/includes/introduction/_references.md b/slate/source/includes/introduction/_references.md
index dce5e536..20b61c70 100644
--- a/slate/source/includes/introduction/_references.md
+++ b/slate/source/includes/introduction/_references.md
@@ -1,13 +1,5 @@
 ## Normative References
 
-```diff
-Removed legacy FAPI references:
-- FAPI-R-Draft
-- FAPI-RW-Draft
-
-Updated PAR references to refer to RFC9126
-```
-
 | **Reference**  | **Description**  | **Version** |
 | --- | --- | --- |
 | <a id="nref-DCR"></a>**[DCR]**          | OAuth 2.0 Dynamic Client Registration Protocol: <https://datatracker.ietf.org/doc/html/rfc7591>                                                                                |Jul 2015
diff --git a/slate/source/includes/known-issues.md b/slate/source/includes/known-issues.md
index 1dd4d68e..5d5118db 100644
--- a/slate/source/includes/known-issues.md
+++ b/slate/source/includes/known-issues.md
@@ -2,9 +2,13 @@
 
 There are certain aspects of the standards that are actively under review. These known issues are articulated in the following table.
 
+```diff
+The known issue related to the incorrect obligation date for
+Get Metrics v5 has been removed as it has been resolved
+```
+
 Issue | Description
 :---- | :----------
-Incorrect obligation date for Get Metrics v5 | The future dated obligation date has been incorrectly documented in the standards as June 13th 2024.  This was a documentation error when v1.25.0 of the standards were published.  According to the decision of the Data Standards Chair (Decision 288) the obligation date for the implementation of Get Metrics v5 is **May 13th 2024**.  This will be corrected in the next release of the standards.
 Register APIs use local version of common definitions | The Register APIs use a locally defined version of common schema definitions such as `ResponseErrorList` for error responses. These need to be updated to reference common swagger specifications inherited by the Common Swagger spec.
 Register APIs use different field type definitions | The Register APIs define their own field types that are not consistent with the [Common Field Types](#common-field-types) defined in the data standards. As part of porting the Register standards across to the primary data standards, the field types need to be re-aligned to use the common field type definitions. For example, `string (data-time)` should be changed to `DataTime` and `integer(int32)` should be changed to `PositiveInteger`.
 DCR and Register Swagger naming conventions | The DCR and Register naming conventions are not consistent with the broader data standards. Field names should be standardised to camelCase and snake_case inline with the data standards
diff --git a/slate/source/includes/nfrs/_data-recipient-requirements.md b/slate/source/includes/nfrs/_data-recipient-requirements.md
index b7feeb7b..e315496b 100644
--- a/slate/source/includes/nfrs/_data-recipient-requirements.md
+++ b/slate/source/includes/nfrs/_data-recipient-requirements.md
@@ -6,10 +6,6 @@ Data Recipient Software Products will be limited by the traffic thresholds docum
 - Services should schedule unattended calls to avoid high traffic periods
 - Unattended calls should be managed to avoid short term bursts of traffic
 
-```diff
-+ Added the Low Velocity Data Sets section
-```
-
 ### Low Velocity Data Sets
 For endpoints that provide access to data that is low velocity (ie. the data does not change frequently) the Data Recipient Software Product is expected to cache the results of any data they receive and not request the same resource again until the data may reasonably have changed.
 
diff --git a/slate/source/includes/nfrs/_traffic-thresholds.md b/slate/source/includes/nfrs/_traffic-thresholds.md
index 054f01b3..8fe719cf 100644
--- a/slate/source/includes/nfrs/_traffic-thresholds.md
+++ b/slate/source/includes/nfrs/_traffic-thresholds.md
@@ -22,11 +22,6 @@ For Unattended traffic the following traffic thresholds will apply for low traff
 
 For Unattended traffic during high traffic periods only best effort support is required.
 
-```diff
-Updated the static site wide TPS thresholds with a graduated set of
-thresholds depending on the number of active authorisations established
-with the data holder
-```
 For secure traffic (both Customer Present and Unattended) the following traffic thresholds will apply:
 
 - For Data Holders with 0 to 10,000 active authorisations, 150 peak TPS total across all consumers
diff --git a/slate/source/includes/obsolete/get-metrics-v3.html.md b/slate/source/includes/obsolete/get-metrics-v3.html.md
index a91ffa9a..9d799abf 100644
--- a/slate/source/includes/obsolete/get-metrics-v3.html.md
+++ b/slate/source/includes/obsolete/get-metrics-v3.html.md
@@ -13,7 +13,9 @@ search: false
 # Get Metrics V3
 This page documents the deprecated version 3 of the Get Metrics end point.
 
-This version does not yet have an obsolescence date and must continue to be supported by data holders.
+Support for this version is not required for Data Holders going live on, or after, 1st November 2023.
+
+Other Data Holders **MAY** retire this version from the earlier of **13th May 2023** or from the time ACCC announce that they no longer call this version.
 
 ## Get Metrics
 
diff --git a/slate/source/includes/obsolete/get-metrics-v4.html.md b/slate/source/includes/obsolete/get-metrics-v4.html.md
index f7cefb26..67b6bd81 100644
--- a/slate/source/includes/obsolete/get-metrics-v4.html.md
+++ b/slate/source/includes/obsolete/get-metrics-v4.html.md
@@ -13,7 +13,7 @@ search: false
 # Get Metrics V4
 This page documents the deprecated version 4 of the Get Metrics end point.
 
-This version must be implemented by **November 1st 2023** and may be obsoleted once v5 has been implemented
+This version **MUST** be implemented by **November 1st 2023** and **MAY** be retured once v5 has been implemented
 
 
 ## Get Metrics
diff --git a/slate/source/includes/releasenotes/releasenotes.1.26.0.html.md b/slate/source/includes/releasenotes/releasenotes.1.26.0.html.md
new file mode 100644
index 00000000..10b2b9df
--- /dev/null
+++ b/slate/source/includes/releasenotes/releasenotes.1.26.0.html.md
@@ -0,0 +1,64 @@
+---
+title: Consumer Data Standards - v1.26.0 Release Notes
+
+#language_tabs: # must be one of https://git.io/vQNgJ
+
+toc_footers:
+  - <a href='../../index.html'>Consumer Data Standards</a>
+
+search: false
+---
+
+# V1.26.0 Release Notes
+Release notes for version v1.26.0 of the [CDR Standards](../../index.html).
+
+## Changes Made
+### Change Requests
+
+This release addresses the following minor defects raised on [Standards Staging](https://github.com/ConsumerDataStandardsAustralia/standards-staging/issues):
+
+- TBD
+
+This release addresses the following change requests raised on [Standards Maintenance](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues):
+
+- None
+
+### Decision Proposals
+
+This release addresses the following Decision Proposals published on [Standards](https://github.com/ConsumerDataStandardsAustralia/standards/issues):
+
+- [Decision Proposal 322 - Update Get Metrics Endpoint Schedule](https://github.com/ConsumerDataStandardsAustralia/standards/issues/322)
+
+## Introduction
+
+No Change
+
+## High Level Standards
+
+No Change
+
+## API End Points
+
+|Change|Description|Link|
+|------|-----------|----|
+| Modified Get Metrics Obligations | Changes to the obligation dates for Get Metrics v3 as determined in [Decision 322](https://github.com/ConsumerDataStandardsAustralia/standards/issues/322) | [Admin APIs](../../#admin-apis) |
+
+## Information Security Profile
+
+No Change
+
+## Register Standards
+
+No Change
+
+## Consumer Experience
+
+No Change
+
+## Non Functional Requirements
+
+No Change
+
+## Known Issues
+
+Resolved the known issue related to the incorrect obligation date for Get Metrics v5
diff --git a/slate/source/includes/security/_authentication_flows.md b/slate/source/includes/security/_authentication_flows.md
index 3da6b18e..34414d98 100644
--- a/slate/source/includes/security/_authentication_flows.md
+++ b/slate/source/includes/security/_authentication_flows.md
@@ -34,9 +34,6 @@ In line with CDR Rule 4.24 on restrictions when asking CDR consumers to authoris
 - offering additional or alternative services
 - reference or inclusion of other documents
 
-```diff
-Removed legacy phasing requirements for FAPI 1.0 Final
-```
 * Data Holders **MUST** support FAPI 1.0 Advanced Profile (**[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)**).
 * Data Holders **MUST** support Authorization Code Flow.  
 * Data Holders **MUST** support the OIDC Hybrid Flow.
@@ -52,10 +49,6 @@ The following statements are applicable to both the OIDC Hybrid Flow and Authori
 
 - Data Recipient Software Products **SHOULD** record the following information each time an authorisation flow is executed: username (consumer’s ID at the Data Recipient Software Product), timestamp, IP, consent scopes and duration.
 
-```diff
-Removed legacy phasing requirements for FAPI 1.0 Final
-```
-
 * Data Recipient Software Products **SHOULD NOT** reuse "authorization_code" values, and if reused, it will be rejected.
 * Data Recipient Software Products **MAY** send requests with a "x-fapi-customer-ip-address" header containing a valid IPv4 or IPv6 address.
 * Data Recipient Software Products **MUST** support FAPI 1.0 Advanced Profile (**[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)**).
diff --git a/slate/source/includes/security/_client_registration.md.erb b/slate/source/includes/security/_client_registration.md.erb
index 821f614d..b9c31840 100644
--- a/slate/source/includes/security/_client_registration.md.erb
+++ b/slate/source/includes/security/_client_registration.md.erb
@@ -8,10 +8,6 @@ Data Recipients register with Data Holders according to **[[DCR]](#nref-DCR)** t
 As per **[[DCR]](#nref-DCR)**, a Software Statement is defined in as: _A digitally signed JSON Web Token (JWT) created in accordance with **[[JWT]](#nref-JWT)** that asserts metadata values about the client software_
 > An SSA is a digitally signed JSON Web Token (JWT) created in accordance with **[[JWT]](#nref-JWT)** that asserts metadata values about the client software.
 
-```diff
-Replaced FAPI draft references with FAPI 1.0 Final references
-```
-
 Such that:
 
 * The CDR Register **MUST** issue Software Statements to **active** Data Recipients for **active** Software Products
@@ -232,9 +228,6 @@ Accept: application/json
 }
 ```
 
-```diff
-Replaced FAPI draft references with FAPI 1.0 Final references
-```
 To register with a Data Holder, the Data Recipient sends an HTTP POST to the Data Holder registration endpoint.
 
 * The request **MUST** be presented in the format of a **[[RFC7519]](#nref-RFC7519)** compliant JWT.
@@ -243,10 +236,6 @@ To register with a Data Holder, the Data Recipient sends an HTTP POST to the Dat
 
 The client registration request **MUST** contain the following claims in the JWT payload unless designated as Optional:
 
-```diff
-Replaced FAPI draft references with FAPI 1.0 Final references
-```
-
 | Claim | Required | Description
 |--------------|-------|-----------------------------------------------------------------------------------------------
 |**iss**|	Required | Contains the identifier for the Data Recipient Software Product (SoftwareProductId) as defined in the CDR Register
@@ -284,10 +273,6 @@ Data Holders **MUST** support at a minimum, 1 algorithm for each claim.
 
 Data Recipients **MUST** support all the algorithms used in the ecosystem to ensure they can communicate with all Data Holders.
 
-```diff
-Replaced FAPI draft references with FAPI 1.0 Final references
-```
-
 ID Token algorithm considerations remain relevant where the OIDC Hybrid Flow is leveraged as defined in the Consumer Data Standards and in accordance with sections [5.1.1](https://openid.net/specs/openid-financial-api-part-2-1_0.html#id-token-as-detached-signature), [5.2.2.1](https://openid.net/specs/openid-financial-api-part-2-1_0.html#id-token-as-detached-signature-1), and [5.2.3.1](https://openid.net/specs/openid-financial-api-part-2-1_0.html#id-token-as-detached-signature-2) of **[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)**.
 
 #### JARM Response Encryption Considerations
diff --git a/slate/source/includes/security/_overview.md b/slate/source/includes/security/_overview.md
index 674447bd..11eb767b 100644
--- a/slate/source/includes/security/_overview.md
+++ b/slate/source/includes/security/_overview.md
@@ -1,16 +1,11 @@
 
 ## Overview
 
-
-```diff
-Removed legacy phasing of FAPI draft specifications. Only FAPI 1.0 Final is relied upon.
-```
 This information security profile builds upon the foundations of the [Financial-grade API Advanced Profile](https://openid.net/specs/openid-financial-api-part-2-1_0.html) **[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)** and other standards relating to
 [Open ID Connect 1.0](http://openid.net/specs/openid-connect-core-1_0.html) **[[OIDC]](#nref-OIDC)**.
 
 For information on the specific normative references that underpin this profile refer to the [Normative References section](#normative-references).
 
-
 ### Symbols and Abbreviated terms
 -   **API**: Application Programming Interface
 -   **CA**: Certificate Authority
diff --git a/slate/source/includes/security/_request_object.md b/slate/source/includes/security/_request_object.md
index fc5f162a..f06776f6 100644
--- a/slate/source/includes/security/_request_object.md
+++ b/slate/source/includes/security/_request_object.md
@@ -36,10 +36,6 @@
 
 > Non-Normative Example - FAPI 1.0 Final Phase 3 Obligation  
 
-```diff
-+ Added "response_mode" to the non normative example. This demonstrates the use of Authorization Code Flow in conjunction with JARM and FAPI 1.0
-```
-
 ```
 #Decoded Request Object JWT
 
@@ -75,10 +71,6 @@
 }
 ```
 
-```diff
-Replaced FAPI draft references with FAPI 1.0 Final references
-```
-
 The Request Object is a signed and encoded JWT specified in [section 6.1](https://openid.net/specs/openid-connect-core-1_0.html#RequestObject) of **[OIDC]**.  As per **[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)** [section 5.2.2](https://openid.net/specs/openid-financial-api-part-2-1_0.html#authorization-server), the `request` parameter **MUST** be present on requests to the **[OIDC]** Hybrid Authorisation End Point. The Request Object enables **[OIDC]** requests to be passed in a single and self-contained parameter.
 
 Request Objects **MUST** be signed by Data Recipient Software Products as specified in [section 8.6](https://openid.net/specs/openid-financial-api-part-2-1_0.html#algorithm-considerations) of **[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)**.
@@ -124,10 +116,6 @@ In addition:
 
 Data Holders **MUST** support Pushed Authorisation Requests (PAR) via the pushed authorisation end point according to **[[PAR]](#nref-PAR)**.
 
-```diff
-Removed legacy phasing requirements for FAPI 1.0 Final
-```
-
 * Data Holders **MUST** support **[[RFC9126]](#nref-RFC9126)** (PAR) using **[[PKCE]](#nref-PKCE)** (**[[RFC7636]](#nref-RFC7636)**) with S256 as the code challenge method in accordance with **[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)** [section 5.2.2](https://openid.net/specs/openid-financial-api-part-2-1_0.html#authorization-server).
 *	Data Holders **MUST** require PAR for authorisation request data in accordance with **[[RFC9126]](#nref-RFC9126)** where "require_pushed_authorization_requests" parameter is set to "true".
 *	Data Holders **MUST** require the request object to contain an "exp" claim that has a lifetime of no longer than 60 minutes after the "nbf" claim in accordance with **[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)** [section 5.2.2](https://openid.net/specs/openid-financial-api-part-2-1_0.html#authorization-server).
@@ -137,10 +125,6 @@ Removed legacy phasing requirements for FAPI 1.0 Final
 
 #### Data Recipient Software Products
 
-```diff
-Removed legacy phasing requirements for FAPI 1.0 Final
-```
-
 *	Data Recipients Software Products **MUST** send request object containing a "nbf" claim and an "exp" claim that has a lifetime of no longer than 60 minutes after the "nbf" claim.
 * Data Recipient Software Products **MUST** ONLY use a "request_uri" value once
 * Data Recipients **MUST** ONLY send authorisation request data using **[[RFC9126]](#nref-RFC9126)** (PAR) and use **[[PKCE]](#nref-PKCE)** (**[[RFC7636]](#nref-RFC7636)**) in accordance with **[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)**.
diff --git a/slate/source/includes/security/_tokens.md b/slate/source/includes/security/_tokens.md
index 38a99568..d1d2e520 100644
--- a/slate/source/includes/security/_tokens.md
+++ b/slate/source/includes/security/_tokens.md
@@ -39,10 +39,6 @@ ID Tokens are specified in [section 2](https://openid.net/specs/openid-connect-c
 
 #### Baseline ID Token requirements
 
-```diff
-Replaced FAPI draft references with FAPI 1.0 Final references
-```
-
 In addition to the mandatory claims specified in [section 2](https://openid.net/specs/openid-connect-core-1_0.html#IDToken) of the **[[OIDC]](#nref-OIDC)** standard, required claims for ID Tokens as part of Hybrid Flow authentication **MUST** align to [section 3.3](https://openid.net/specs/openid-connect-core-1_0.html#HybridFlowAuth) (Authentication using the Hybrid Flow) of the **[[OIDC]](#nref-OIDC)** standards and [section 5.2.2](https://openid.net/specs/openid-financial-api-part-2-1_0.html#authorization-server) and [section 8.4.3](https://openid.net/specs/openid-financial-api-part-2-1_0.html#authorization-response-parameter-injection-attack) of the **[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)** profile.
 
 ID Tokens **MUST** be signed by Data Holders as specified in [section 8.6](https://openid.net/specs/openid-financial-api-part-2-1_0.html#algorithm-considerations) of **[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)**.
@@ -50,19 +46,12 @@ ID Tokens **MUST** be signed by Data Holders as specified in [section 8.6](https
 
 #### OIDC Hybrid Flow requirements
 
-```diff
-Replaced FAPI draft references with FAPI 1.0 Final references
-```
-
 In accordance with **[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)**, ID Tokens **MUST** be signed and encrypted when returned to a Data Recipient Software Product from both the Authorisation End Point and Token End Point.
 
 The ID Token returned from the Authorisation End Point **MUST NOT** contain any Personal Information (PI) claims.
 
 ##### Hashing value for state and authorisation code
 
-```diff
-Replaced FAPI draft references with FAPI 1.0 Final references
-```
 The following requirements apply to the OIDC Hybrid Flow:
 
 * The `c_hash` value **MUST** be generated according to [section 3.3.2.11](https://openid.net/specs/openid-connect-core-1_0.html#HybridIDToken) of **[[OIDC]](#nref-OIDC)**.
@@ -80,10 +69,6 @@ An Access Token **MUST** expire between **2 minutes** to **10 minutes** after th
 The process for refreshing an Access Token is described in [section 12.1](https://openid.net/specs/openid-connect-core-1_0.html#RefreshingAccessToken) of **[[OIDC]](#nref-OIDC)**.
 
 
-```diff
-Removed legacy phasing requirements for FAPI 1.0 Final
-```
-
 * Data Holders **MUST** reject token request with an authorization code (Section 1.3.1 of **[[RFC6749]](#nref-RFC6749)**) if it has been previously used
 
 
@@ -96,10 +81,6 @@ The expiration time for a Refresh Token **MUST** be set by the Data Holder.
 
 Refresh Token expiration **MAY** be any length of time greater than 28 days but **MUST NOT** exceed the end of the duration of sharing consented to by the Consumer.
 
-```diff
-Removed legacy phasing requirements for FAPI 1.0 Final
-```
-
 *	Data Holders **MUST NOT** cycle refresh tokens (rotation). In other words, Refresh Tokens **SHOULD** be issued with an "exp" equal to the sharing duration authorised by the Customer.
 
 ### Token Expiry
@@ -107,9 +88,4 @@ The expiry time for issued access tokens and refresh tokens **MUST** be determin
 
 In order to achieve this:
 
-```diff
-Removed legacy phasing requirements for FAPI 1.0 Final
-```
-
 - The Data Holder **MUST** indicate the lifetime in seconds of the access token in the `expires_in` field of the JSON object returned by the token end-point (see [section 4.2.2] (https://tools.ietf.org/html/rfc6749#section-4.2.2) of **[[OAUTH2]](#nref-OAUTH2)**).
-
diff --git a/slate/source/includes/security/_transport_security.md b/slate/source/includes/security/_transport_security.md
index ef308bc5..b69ef042 100644
--- a/slate/source/includes/security/_transport_security.md
+++ b/slate/source/includes/security/_transport_security.md
@@ -24,9 +24,7 @@ OAUTB SHALL NOT be supported due to a lack industry support.
 **[[MTLS]](#nref-MTLS)** HoK allows issued tokens to be bound to a client certificate as specified in [section 3](https://tools.ietf.org/id/draft-ietf-oauth-mtls-07.html#SenderConstrainedAccess) of **[[MTLS]](#nref-MTLS)**.
 
 ### Ciphers
-```diff
-Replaced FAPI draft RW references with FAPI 1.0 Final Advanced references. References pertain to the TLS considerations.
-```
+
 Only the following cipher suites SHALL be permitted in accordance with [section 8.5](https://openid.net/specs/openid-financial-api-part-2-1_0.html#tls-considerations) of **[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)**:
 
 -   TLS\_DHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256
diff --git a/slate/source/includes/security/endpoints/_authorisation.md b/slate/source/includes/security/endpoints/_authorisation.md
index 50c0706d..a5136149 100644
--- a/slate/source/includes/security/endpoints/_authorisation.md
+++ b/slate/source/includes/security/endpoints/_authorisation.md
@@ -55,7 +55,7 @@ Host: www.holder.com.au
 
 > Non-Normative Example - FAPI 1.0 Final Phase 3 Obligation
 > This example demonstrates how an ADR may send a staged authorisation request (using PAR) in the back-channel to the Data Holder.   
-> 
+>
 > It demonstrates a FAPI 1.0 Final compliant authorisation request using the PAR to first submit the authorisation request object.  
 
 ```
@@ -76,10 +76,6 @@ Host: www.holder.com.au
 | Client Authentication Required| No|
 | Bearer Token Required| No|
 
-```diff
-Replaced FAPI draft references with FAPI 1.0 Final references
-```
-
 The requirements for the Authorisation End Point are specified in [section 3.3.2](https://openid.net/specs/openid-connect-core-1_0.html#HybridAuthorizationEndpoint) of **[[OIDC]](#nref-OIDC)** and further specified under section [5.2.2](https://openid.net/specs/openid-financial-api-part-2-1_0.html#authorization-server) of **[[FAPI-1.0-Advanced]](#nref-FAPI-1-0-Advanced)**.  This end point is invoked as part of the [Hybrid Authentication flow](#hybrid-flow).
 
 This endpoint does not require [CORS](https://consumerdatastandardsaustralia.github.io/standards/#cors).
diff --git a/slate/source/includes/security/endpoints/_oidc_provider_configuration.md b/slate/source/includes/security/endpoints/_oidc_provider_configuration.md
index 525522e7..00328234 100644
--- a/slate/source/includes/security/endpoints/_oidc_provider_configuration.md
+++ b/slate/source/includes/security/endpoints/_oidc_provider_configuration.md
@@ -2,10 +2,6 @@
 
 > Non-Normative Example
 
-```diff
-+ Adds examples for all metadata parameters required by the Data Standards and upstream normative references
-```
-
 ```
 ## Request
 
@@ -36,18 +32,18 @@ Content-Type: application/json
   "token_endpoint_auth_methods_supported": ["private_key_jwt"],
   "token_endpoint_auth_signing_alg_values_supported": ["ES256", "PS256"],
   "userinfo_endpoint": "https://www.dh.com.au/userinfo",
-  
+
   "code_challenge_methods_supported": "S256",
   "introspection_endpoint": "https://www.dh.com.au/introspect",
   "revocation_endpoint": "https://www.dh.com.au/revoke",
-  
+
   "tls_client_certificate_bound_access_tokens": true,
 
   "pushed_authorization_request_endpoint": "https://data.holder.com.au/par",
   "require_pushed_authorization_requests": true,
-  
+
   "authorization_encryption_alg_values_supported": ["RSA-OAEP", "RSA-OAEP-256"],
-  
+
   "authorization_encryption_enc_values_supported": ["A256GCM", "A128CBC-HS256"],
   "authorization_signing_alg_values_supported": ["ES256", "PS256"],
 
@@ -66,11 +62,6 @@ Data Holders MUST make their OpenID Provider Metadata available via a configurat
 
 This endpoint does not require [CORS](https://consumerdatastandardsaustralia.github.io/standards/#cors).
 
-```diff
-Replaced FAPI draft references with FAPI 1.0 Final references
-
-+ Adds all metadata parameters required by the Data Standards and upstream normative references
-```
 At a minimum, the Data Holder metadata **MUST** include:
 
 **[[OIDD]](#nref-OIDD)**
@@ -81,11 +72,11 @@ At a minimum, the Data Holder metadata **MUST** include:
 - `grant_types_supported`: The list of the OAuth 2.0 Grant Type values supported
 - `id_token_encryption_alg_values_supported`: The list of the supported JWE algorithms for securing the issued ID tokens. Must conform to **[[FAPI-RW-Draft]](#nref-FAPI-RW-Draft)** and **[[OIDD]](#nref-OIDD)**. Required for Data Holders supporting OIDC Hybrid Flow
 - `id_token_encryption_enc_values_supported`: The list of the supported JWE encryption methods for securing the issued ID tokens. Required for Data Holders supporting OIDC Hybrid Flow
-- `id_token_signing_alg_values_supported`: The list of the JWS signing algorithms (`alg` values) supported 
+- `id_token_signing_alg_values_supported`: The list of the JWS signing algorithms (`alg` values) supported
 - `issuer`: URL that the Data Holder asserts as its Issuer Identifier
 - `jwks_uri`: The JSON Web Key Set for the data holder
 - `registration_endpoint`: URL of the Client Registration End Point
-- `request_object_signing_alg_values_supported`: The list of the JWS signing algorithms (`alg` values) supported for signing request objects. 
+- `request_object_signing_alg_values_supported`: The list of the JWS signing algorithms (`alg` values) supported for signing request objects.
 - `response_modes_supported`: The list of the OAuth 2.0 `response_mode` values supported
 - `response_types_supported`: The list of the OAuth 2.0 `response_type` values supported
 - `scopes_supported`:  The list of supported scopes
@@ -122,4 +113,3 @@ Where Data Holders support authorisation response encryption according to **[[JA
 In addition, the Data Holder metadata **MUST** also include:
 
 - `cdr_arrangement_revocation_endpoint`: The URL of the CDR Arrangement Revocation End Point for consent revocation
-
diff --git a/slate/source/includes/security/endpoints/_par.md b/slate/source/includes/security/endpoints/_par.md
index bd1ff1dd..a0419401 100644
--- a/slate/source/includes/security/endpoints/_par.md
+++ b/slate/source/includes/security/endpoints/_par.md
@@ -1,10 +1,6 @@
 
 ### Pushed Authorisation End Point
 
-```diff
-Updated non-normtative example to use RFC9126, not the draft PAR specification
-```
-
 > Non-Normative Example  
 > Utilising RFC9126 and OIDC Hybrid Flow
 
@@ -94,10 +90,6 @@ request=eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjEyMyJ9.ey...
 > Decoded Request - FAPI 1.0 Final Phase 3 Obligation  
 This example shows an authorisation request using the Authorisation Code Flow (FAPI 1.0 migration Phase 3)
 
-```diff
-+ Added "response_mode" to the non normative example. This demonstrates the use of Authorization Code Flow in conjunction with JARM and FAPI 1.0
-```
-
 ```
 {
   "iss": "s6BhdRkqt3",
@@ -183,10 +175,6 @@ eyJraWQiOiIwZWQ3YTNkZi1hMGJlLTRhZjQtOTk0YS1jNDBhODc0ODQwNjMiLCJhbGciOiJQUzI1NiJ9
 
 Data Holders **MUST** support Pushed Authorisation Requests (PAR) via the pushed authorisation end point according to **[[PAR]](#nref-PAR)**.
 
-```diff
-- Removed legacy phasing requirements for FAPI 1.0 Final using PAR
-```
-
 Data Recipient Software Products **MUST** send authorisation requests using **[[PAR]](#nref-PAR)** if supported by the Data Holder.
 
 The Data Holder response provides the Data Recipient Software Product with a Request URI in the response. The Request URI is then passed to the Data Holder’s Authorisation End Point to initiate an authorisation flow.
diff --git a/slate/source/includes/standards/_headers.md b/slate/source/includes/standards/_headers.md
index 20bfe38f..65e0dde3 100644
--- a/slate/source/includes/standards/_headers.md
+++ b/slate/source/includes/standards/_headers.md
@@ -28,11 +28,6 @@ Supported HTTP headers, and their usage, for the standards are as laid out in th
 `Accept-Encoding: charset=UTF-8`  
 `Accept: AppliCAtion/JSon;Charset=uTf-8`  
 
-```diff
-Replaced FAPI draft references with FAPI 1.0 Final references.
-References pertain to the x-fapi-auth-date header.
-```
-
 Header Field | Description | Mandatory?
 -------------|-------------|-----------
 **Content-Type** | Standard HTTP Header. Represents the format of the payload provided in the request. The media type must be set to `application/json`. Mandatory for PUT and POST calls.| Conditional
diff --git a/slate/source/includes/swagger/cds_admin.json b/slate/source/includes/swagger/cds_admin.json
index 39dee4f9..d3b4f529 100644
--- a/slate/source/includes/swagger/cds_admin.json
+++ b/slate/source/includes/swagger/cds_admin.json
@@ -12,7 +12,7 @@
       "url" : "https://opensource.org/licenses/MIT"
     },
     "title" : "CDR Admin API",
-    "version" : "1.25.0"
+    "version" : "1.26.0"
   },
   "servers" : [ {
     "url" : "https://data.holder.com.au/cds-au/v1"
@@ -103,7 +103,7 @@
     },
     "/admin/metrics" : {
       "get" : {
-        "description" : "This end point allows the ACCC to obtain operational statistics from the Data Holder (at the Data Holder Brand level) on the operation of their CDR compliant implementation. The statistics obtainable from this end point are determined by the non-functional requirements for the CDR regime.\n\nThis end point is not required to be implemented by the Australian Energy Market Operator, the Australian Energy Regulator or the Department of State administered by the Minister of Victoria administering the National Electricity (Victoria) Act 2005 (Vic).\n\nNOTE: This version must be implemented by **June 13th 2024**\n\nObsolete versions: [v1](includes/obsolete/get-metrics-v1.html) [v2](includes/obsolete/get-metrics-v2.html).\n\nDeprecated versions:\n\n- [v3](includes/obsolete/get-metrics-v3.html)\n- [v4](includes/obsolete/get-metrics-v4.html) - This version, or v5, must be implemented by **November 1st 2023**\n\nIf the Data Holder supports private_key_jwt client authentication they MUST validate the scope.",
+        "description" : "This end point allows the ACCC to obtain operational statistics from the Data Holder (at the Data Holder Brand level) on the operation of their CDR compliant implementation. The statistics obtainable from this end point are determined by the non-functional requirements for the CDR regime.\n\nThis end point is not required to be implemented by the Australian Energy Market Operator, the Australian Energy Regulator or the Department of State administered by the Minister of Victoria administering the National Electricity (Victoria) Act 2005 (Vic).\n\nNOTE: This version **MUST** be implemented by **May 13th 2024**\n\nObsolete versions: [v1](includes/obsolete/get-metrics-v1.html) [v2](includes/obsolete/get-metrics-v2.html).\n\nDeprecated versions:\n\n- [v3](includes/obsolete/get-metrics-v3.html) - Implementation not required for Data Holders going live on, or after, 1st November 2023.  Other Data Holders **MAY** retire this version from the earlier of **13th May 2023** or from the time ACCC announce that they no longer call this version\n- [v4](includes/obsolete/get-metrics-v4.html) - This version, or v5, **MUST** be implemented by **November 1st 2023**\n\nIf the Data Holder supports private_key_jwt client authentication they MUST validate the scope.",
         "operationId" : "getMetrics",
         "parameters" : [ {
           "description" : "The period of metrics to be requested. Values can be CURRENT (meaning metrics for current period, dependent on the metric type), HISTORIC (meaning metrics for previous period, depending on the metric type) or ALL. If absent the default is ALL.",
diff --git a/slate/source/includes/swagger/cds_admin.yaml b/slate/source/includes/swagger/cds_admin.yaml
index 4224a198..4d9c5e2b 100644
--- a/slate/source/includes/swagger/cds_admin.yaml
+++ b/slate/source/includes/swagger/cds_admin.yaml
@@ -11,7 +11,7 @@ info:
     name: MIT License
     url: https://opensource.org/licenses/MIT
   title: CDR Admin API
-  version: 1.25.0
+  version: 1.26.0
 servers:
 - url: https://data.holder.com.au/cds-au/v1
 paths:
@@ -99,14 +99,14 @@ paths:
 
         This end point is not required to be implemented by the Australian Energy Market Operator, the Australian Energy Regulator or the Department of State administered by the Minister of Victoria administering the National Electricity (Victoria) Act 2005 (Vic).
 
-        NOTE: This version must be implemented by **June 13th 2024**
+        NOTE: This version **MUST** be implemented by **May 13th 2024**
 
         Obsolete versions: [v1](includes/obsolete/get-metrics-v1.html) [v2](includes/obsolete/get-metrics-v2.html).
 
         Deprecated versions:
 
-        - [v3](includes/obsolete/get-metrics-v3.html)
-        - [v4](includes/obsolete/get-metrics-v4.html) - This version, or v5, must be implemented by **November 1st 2023**
+        - [v3](includes/obsolete/get-metrics-v3.html) - Implementation not required for Data Holders going live on, or after, 1st November 2023.  Other Data Holders **MAY** retire this version from the earlier of **13th May 2023** or from the time ACCC announce that they no longer call this version
+        - [v4](includes/obsolete/get-metrics-v4.html) - This version, or v5, **MUST** be implemented by **November 1st 2023**
 
         If the Data Holder supports private_key_jwt client authentication they MUST validate the scope.
       operationId: getMetrics
diff --git a/slate/source/includes/swagger/cds_banking.json b/slate/source/includes/swagger/cds_banking.json
index 34a6ea49..2e1b188a 100644
--- a/slate/source/includes/swagger/cds_banking.json
+++ b/slate/source/includes/swagger/cds_banking.json
@@ -12,7 +12,7 @@
       "url" : "https://opensource.org/licenses/MIT"
     },
     "title" : "CDR Banking API",
-    "version" : "1.25.0"
+    "version" : "1.26.0"
   },
   "servers" : [ {
     "url" : "https://data.holder.com.au/cds-au/v1"
diff --git a/slate/source/includes/swagger/cds_banking.yaml b/slate/source/includes/swagger/cds_banking.yaml
index 4aa84cfd..71c6c308 100644
--- a/slate/source/includes/swagger/cds_banking.yaml
+++ b/slate/source/includes/swagger/cds_banking.yaml
@@ -11,7 +11,7 @@ info:
     name: MIT License
     url: https://opensource.org/licenses/MIT
   title: CDR Banking API
-  version: 1.25.0
+  version: 1.26.0
 servers:
 - url: https://data.holder.com.au/cds-au/v1
 paths:
diff --git a/slate/source/includes/swagger/cds_common.json b/slate/source/includes/swagger/cds_common.json
index 21b25e4d..a008df9e 100644
--- a/slate/source/includes/swagger/cds_common.json
+++ b/slate/source/includes/swagger/cds_common.json
@@ -12,7 +12,7 @@
       "url" : "https://opensource.org/licenses/MIT"
     },
     "title" : "CDR Common API",
-    "version" : "1.25.0"
+    "version" : "1.26.0"
   },
   "servers" : [ {
     "url" : "https://data.holder.com.au/cds-au/v1"
diff --git a/slate/source/includes/swagger/cds_common.yaml b/slate/source/includes/swagger/cds_common.yaml
index 1191a04d..11e75e9c 100644
--- a/slate/source/includes/swagger/cds_common.yaml
+++ b/slate/source/includes/swagger/cds_common.yaml
@@ -11,7 +11,7 @@ info:
     name: MIT License
     url: https://opensource.org/licenses/MIT
   title: CDR Common API
-  version: 1.25.0
+  version: 1.26.0
 servers:
 - url: https://data.holder.com.au/cds-au/v1
 paths:
diff --git a/slate/source/includes/swagger/cds_dcr.json b/slate/source/includes/swagger/cds_dcr.json
index ba6399e7..f157e1b4 100644
--- a/slate/source/includes/swagger/cds_dcr.json
+++ b/slate/source/includes/swagger/cds_dcr.json
@@ -3,7 +3,7 @@
   "info" : {
     "description" : "This specification defines the APIs for Data Holders exposing Dynamic Client Registration endpoints.",
     "title" : "CDR Dynamic Client Registration API",
-    "version" : "1.25.0"
+    "version" : "1.26.0"
   },
   "servers" : [ {
     "url" : "https://data.holder.com.au/"
diff --git a/slate/source/includes/swagger/cds_dcr.yaml b/slate/source/includes/swagger/cds_dcr.yaml
index 015a04fc..b64bb755 100644
--- a/slate/source/includes/swagger/cds_dcr.yaml
+++ b/slate/source/includes/swagger/cds_dcr.yaml
@@ -3,7 +3,7 @@ info:
   description: This specification defines the APIs for Data Holders exposing Dynamic
     Client Registration endpoints.
   title: CDR Dynamic Client Registration API
-  version: 1.25.0
+  version: 1.26.0
 servers:
 - url: https://data.holder.com.au/
 paths:
diff --git a/slate/source/includes/swagger/cds_energy.json b/slate/source/includes/swagger/cds_energy.json
index 8ea5cf26..27cb88cc 100644
--- a/slate/source/includes/swagger/cds_energy.json
+++ b/slate/source/includes/swagger/cds_energy.json
@@ -3,7 +3,7 @@
   "info" : {
     "description" : "Consumer Data Right end points and payloads for the Energy sector",
     "title" : "CDR Energy API",
-    "version" : "1.25.0"
+    "version" : "1.26.0"
   },
   "servers" : [ {
     "url" : "/"
diff --git a/slate/source/includes/swagger/cds_energy.yaml b/slate/source/includes/swagger/cds_energy.yaml
index e3a34b42..231ae892 100644
--- a/slate/source/includes/swagger/cds_energy.yaml
+++ b/slate/source/includes/swagger/cds_energy.yaml
@@ -2,7 +2,7 @@ openapi: 3.0.3
 info:
   description: Consumer Data Right end points and payloads for the Energy sector
   title: CDR Energy API
-  version: 1.25.0
+  version: 1.26.0
 servers:
 - url: /
 paths:
diff --git a/slate/source/includes/swagger/cds_energy_sdh.json b/slate/source/includes/swagger/cds_energy_sdh.json
index bea5cd11..83df0445 100644
--- a/slate/source/includes/swagger/cds_energy_sdh.json
+++ b/slate/source/includes/swagger/cds_energy_sdh.json
@@ -3,7 +3,7 @@
   "info" : {
     "description" : "Consumer Data Right end points and payloads for Secondary Data Holder for the Energy sector",
     "title" : "CDR Energy Secondary Data Holder API",
-    "version" : "1.25.0"
+    "version" : "1.26.0"
   },
   "servers" : [ {
     "url" : "/"
diff --git a/slate/source/includes/swagger/cds_energy_sdh.yaml b/slate/source/includes/swagger/cds_energy_sdh.yaml
index 205dace7..e917ee2c 100644
--- a/slate/source/includes/swagger/cds_energy_sdh.yaml
+++ b/slate/source/includes/swagger/cds_energy_sdh.yaml
@@ -3,7 +3,7 @@ info:
   description: Consumer Data Right end points and payloads for Secondary Data Holder
     for the Energy sector
   title: CDR Energy Secondary Data Holder API
-  version: 1.25.0
+  version: 1.26.0
 servers:
 - url: /
 paths:
diff --git a/slate/source/includes/swagger/cds_register.json b/slate/source/includes/swagger/cds_register.json
index 77f75c20..67b17f36 100644
--- a/slate/source/includes/swagger/cds_register.json
+++ b/slate/source/includes/swagger/cds_register.json
@@ -2,7 +2,7 @@
   "openapi" : "3.0.3",
   "info" : {
     "title" : "CDR Participant Discovery API",
-    "version" : "1.25.0"
+    "version" : "1.26.0"
   },
   "servers" : [ {
     "url" : "https://<register-base-url>/"
diff --git a/slate/source/includes/swagger/cds_register.yaml b/slate/source/includes/swagger/cds_register.yaml
index 59cef5e5..2b68399c 100644
--- a/slate/source/includes/swagger/cds_register.yaml
+++ b/slate/source/includes/swagger/cds_register.yaml
@@ -1,7 +1,7 @@
 openapi: 3.0.3
 info:
   title: CDR Participant Discovery API
-  version: 1.25.0
+  version: 1.26.0
 servers:
 - url: https://<register-base-url>/
 paths:
diff --git a/slate/source/includes/swagger/cds_telco.json b/slate/source/includes/swagger/cds_telco.json
index d2833d51..75e68814 100644
--- a/slate/source/includes/swagger/cds_telco.json
+++ b/slate/source/includes/swagger/cds_telco.json
@@ -12,7 +12,7 @@
       "url" : "https://opensource.org/licenses/MIT"
     },
     "title" : "CDR Telco API",
-    "version" : "1.25.0"
+    "version" : "1.26.0"
   },
   "servers" : [ {
     "url" : "https://data.holder.com.au/cds-au/v1"
diff --git a/slate/source/includes/swagger/cds_telco.yaml b/slate/source/includes/swagger/cds_telco.yaml
index eadaadf8..fe6475bd 100644
--- a/slate/source/includes/swagger/cds_telco.yaml
+++ b/slate/source/includes/swagger/cds_telco.yaml
@@ -11,7 +11,7 @@ info:
     name: MIT License
     url: https://opensource.org/licenses/MIT
   title: CDR Telco API
-  version: 1.25.0
+  version: 1.26.0
 servers:
 - url: https://data.holder.com.au/cds-au/v1
 paths:
diff --git a/swagger-gen/api/cds_admin.json b/swagger-gen/api/cds_admin.json
index 9d1b8e04..1d9caf7f 100644
--- a/swagger-gen/api/cds_admin.json
+++ b/swagger-gen/api/cds_admin.json
@@ -12,7 +12,7 @@
       "name": "MIT License",
       "url": "https://opensource.org/licenses/MIT"
     },
-    "version": "1.25.0"
+    "version": "1.26.0"
   },
   "servers": [
     {
@@ -111,7 +111,7 @@
           "Metrics"
         ],
         "summary": "Get Metrics",
-        "description": "This end point allows the ACCC to obtain operational statistics from the Data Holder (at the Data Holder Brand level) on the operation of their CDR compliant implementation. The statistics obtainable from this end point are determined by the non-functional requirements for the CDR regime.\n\nThis end point is not required to be implemented by the Australian Energy Market Operator, the Australian Energy Regulator or the Department of State administered by the Minister of Victoria administering the National Electricity (Victoria) Act 2005 (Vic).\n\nNOTE: This version must be implemented by **June 13th 2024**\n\nObsolete versions: [v1](includes/obsolete/get-metrics-v1.html) [v2](includes/obsolete/get-metrics-v2.html).\n\nDeprecated versions:\n\n- [v3](includes/obsolete/get-metrics-v3.html)\n- [v4](includes/obsolete/get-metrics-v4.html) - This version, or v5, must be implemented by **November 1st 2023**\n\nIf the Data Holder supports private_key_jwt client authentication they MUST validate the scope.",
+        "description": "This end point allows the ACCC to obtain operational statistics from the Data Holder (at the Data Holder Brand level) on the operation of their CDR compliant implementation. The statistics obtainable from this end point are determined by the non-functional requirements for the CDR regime.\n\nThis end point is not required to be implemented by the Australian Energy Market Operator, the Australian Energy Regulator or the Department of State administered by the Minister of Victoria administering the National Electricity (Victoria) Act 2005 (Vic).\n\nNOTE: This version **MUST** be implemented by **May 13th 2024**\n\nObsolete versions: [v1](includes/obsolete/get-metrics-v1.html) [v2](includes/obsolete/get-metrics-v2.html).\n\nDeprecated versions:\n\n- [v3](includes/obsolete/get-metrics-v3.html) - Implementation not required for Data Holders going live on, or after, 1st November 2023.  Other Data Holders **MAY** retire this version from the earlier of **13th May 2023** or from the time ACCC announce that they no longer call this version\n- [v4](includes/obsolete/get-metrics-v4.html) - This version, or v5, **MUST** be implemented by **November 1st 2023**\n\nIf the Data Holder supports private_key_jwt client authentication they MUST validate the scope.",
         "operationId": "getMetrics",
         "parameters": [
           {
diff --git a/swagger-gen/api/cds_banking.json b/swagger-gen/api/cds_banking.json
index 0c16d47f..a05c888a 100644
--- a/swagger-gen/api/cds_banking.json
+++ b/swagger-gen/api/cds_banking.json
@@ -12,7 +12,7 @@
       "name": "MIT License",
       "url": "https://opensource.org/licenses/MIT"
     },
-    "version": "1.25.0"
+    "version": "1.26.0"
   },
   "servers": [
     {
@@ -5465,7 +5465,7 @@
             "enum": [
               "accountId",
               "biller",
-              "digitalWallet",              
+              "digitalWallet",
               "domestic",
               "international",
               "payeeId"
@@ -5491,7 +5491,7 @@
           },
           "digitalWallet": {
             "$ref": "#/components/schemas/BankingDigitalWalletPayee"
-          },        
+          },
           "domestic": {
             "$ref": "#/components/schemas/BankingDomesticPayee"
           },
diff --git a/swagger-gen/api/cds_common.json b/swagger-gen/api/cds_common.json
index 916d5d0d..167e5fbf 100644
--- a/swagger-gen/api/cds_common.json
+++ b/swagger-gen/api/cds_common.json
@@ -12,7 +12,7 @@
       "name": "MIT License",
       "url": "https://opensource.org/licenses/MIT"
     },
-    "version": "1.25.0"
+    "version": "1.26.0"
   },
   "servers": [
     {
diff --git a/swagger-gen/api/cds_dcr.json b/swagger-gen/api/cds_dcr.json
index 53798a78..0ef35d9d 100644
--- a/swagger-gen/api/cds_dcr.json
+++ b/swagger-gen/api/cds_dcr.json
@@ -3,7 +3,7 @@
   "info": {
     "title": "CDR Dynamic Client Registration API",
     "description": "This specification defines the APIs for Data Holders exposing Dynamic Client Registration endpoints.",
-    "version": "1.25.0"
+    "version": "1.26.0"
   },
   "servers": [
     {
diff --git a/swagger-gen/api/cds_energy.json b/swagger-gen/api/cds_energy.json
index 2a90f1a4..80b3c4bd 100644
--- a/swagger-gen/api/cds_energy.json
+++ b/swagger-gen/api/cds_energy.json
@@ -3,7 +3,7 @@
 	"info": {
 		"title": "CDR Energy API",
 		"description": "Consumer Data Right end points and payloads for the Energy sector",
-        "version": "1.25.0"
+        "version": "1.26.0"
 	},
 	"components": {
 		"schemas": {
diff --git a/swagger-gen/api/cds_energy_sdh.json b/swagger-gen/api/cds_energy_sdh.json
index 4ed8d885..bf07ccc5 100644
--- a/swagger-gen/api/cds_energy_sdh.json
+++ b/swagger-gen/api/cds_energy_sdh.json
@@ -3,7 +3,7 @@
 	"info": {
 		"title": "CDR Energy Secondary Data Holder API",
 		"description": "Consumer Data Right end points and payloads for Secondary Data Holder for the Energy sector",
-        "version": "1.25.0"
+        "version": "1.26.0"
 	},
 	"components": {
 		"schemas": {
diff --git a/swagger-gen/api/cds_register.json b/swagger-gen/api/cds_register.json
index 0effbcf7..1998e7b3 100644
--- a/swagger-gen/api/cds_register.json
+++ b/swagger-gen/api/cds_register.json
@@ -2,7 +2,7 @@
   "openapi": "3.0.3",
   "info": {
     "title": "CDR Participant Discovery API",
-    "version": "1.25.0"
+    "version": "1.26.0"
   },
   "servers": [
     {
diff --git a/swagger-gen/api/cds_telco.json b/swagger-gen/api/cds_telco.json
index 2372882d..a5af6cc5 100644
--- a/swagger-gen/api/cds_telco.json
+++ b/swagger-gen/api/cds_telco.json
@@ -12,7 +12,7 @@
       "url": "https://opensource.org/licenses/MIT"
     },
     "title": "CDR Telco API",
-    "version": "1.25.0"
+    "version": "1.26.0"
   },
   "servers": [ {
     "url": "https://data.holder.com.au/cds-au/v1"
diff --git a/swagger-gen/cds_admin.md b/swagger-gen/cds_admin.md
index eea960a2..adf6ae4a 100644
--- a/swagger-gen/cds_admin.md
+++ b/swagger-gen/cds_admin.md
@@ -145,14 +145,14 @@ This end point allows the ACCC to obtain operational statistics from the Data Ho
 
 This end point is not required to be implemented by the Australian Energy Market Operator, the Australian Energy Regulator or the Department of State administered by the Minister of Victoria administering the National Electricity (Victoria) Act 2005 (Vic).
 
-NOTE: This version must be implemented by **June 13th 2024**
+NOTE: This version **MUST** be implemented by **May 13th 2024**
 
 Obsolete versions: [v1](includes/obsolete/get-metrics-v1.html) [v2](includes/obsolete/get-metrics-v2.html).
 
 Deprecated versions:
 
-- [v3](includes/obsolete/get-metrics-v3.html)
-- [v4](includes/obsolete/get-metrics-v4.html) - This version, or v5, must be implemented by **November 1st 2023**
+- [v3](includes/obsolete/get-metrics-v3.html) - Implementation not required for Data Holders going live on, or after, 1st November 2023.  Other Data Holders **MAY** retire this version from the earlier of **13th May 2023** or from the time ACCC announce that they no longer call this version
+- [v4](includes/obsolete/get-metrics-v4.html) - This version, or v5, **MUST** be implemented by **November 1st 2023**
 
 If the Data Holder supports private_key_jwt client authentication they MUST validate the scope.