diff --git a/slate/source/includes/introduction/_fdo.md b/slate/source/includes/introduction/_fdo.md
index 943985e0..ad828774 100644
--- a/slate/source/includes/introduction/_fdo.md
+++ b/slate/source/includes/introduction/_fdo.md
@@ -1,41 +1,33 @@
## Future Dated Obligations
-The standards, as published from time to time, may include specific statements indicating that a specific section of the standards will not take effect until a future date or may cease to have effect on some future date.
+The standards, as published from time to time, **MAY** include specific statements indicating that a specific section of the standards will not take effect until a future date or **MAY** cease to have effect on some future date.
The table below highlights these areas of the standards.
|Section|Description|Applicable Date|
|-------|-----------|---------------|
-|[Standard Error Codes](#error-codes) | Data Recipients and Data Holders MAY implement the standard error codes from July 1st 2021 | July 1st 2021 |
-|[Get Metrics V2](#get-metrics)|Version 2 of this end point must be made available by affected data holders by the end of July 2021|July 31st 2021|
-|[Get Metrics V1](#get-metrics)|Data holders may obsolete version 1 of this end point from October 31st 2021. Data Holders who go live with consumer data sharing from July 1st 2021 MAY go live with only Get Metrics v2 support. The CDR Register must upgrade their implementation to use version 2 by this time|October 31st 2021|
-|[Amending Consent](#amending-authorisation-standards)|Data Holders MUST implement the following standards from November 1st 2021 when a CDR consumer is invited to amend a current authorisation as per rule 4.22A and the ADR has supplied a `cdr_arrangement_id`|November 1st 2021|
-|[CX Standards: Unavailable Accounts](#authorisation-standards)|Data Holders **MAY** implement the following data standards effective from 1 November 2021:
- **Unavailable Accounts:** No accounts can be shown
- **Unavailable Accounts:** Authorisation not permitted
- **Unavailable Accounts:** Request sharing rights
|November 1st 2021|
-|[CX Standards: Withdrawals](#withdrawal-standards)|Data Holders **MUST** implement the following data standards effective from 1 February 2022:- **Withdrawal:** Secondary User Instruction
|February 1st 2022|
-|[Standard Error Codes](#error-codes) | Data Recipients and Data Holders MUST implement the standard error codes from February 1st 2022 | February 1st 2022 |
-|[Data Recipient CDR Arrangement Endpoint](#cdr-arrangement-revocation-end-point) | From March 31st 2022, Data Recipients **MUST** support "CDR Arrangement JWT" method and "CDR Arrangement Form Parameter" method.
Data Recipients **SHOULD** support the "CDR Arrangement JWT" method before March 31st 2022 | March 31st 2022 |
|[Profile Scope Data Language](#profile-scope)|For new and amended consents and authorisations only, CDR participants **SHOULD** comply with the following standards from 1 February 2022, but **MUST** comply by 1 July 2022:- Technical Standards: Revised Claims
- CX Standards: Profile Scope - Data Language Standards
**Note:** These standards changes **do not** apply to existing consents and authorisations unless they are amended on or following the compliance dates. | July 1st 2022 |
-|[CX Standards: Joint Accounts](#consumer-experience) | Data holders MUST implement the following data standards from 1 July 2022:- Notifications: Alternative notification schedules for joint accounts
- Notifications: Joint account alerts
- Authorisation: Pending status
- Withdrawal: Joint accounts
| July 1st 2022 |
-|[Information Security profile](#security-profile) | FAPI 1.0 adoption is introduced across three phases.
Phase 1: Voluntary FAPI 1.0 support & hygiene enhancements includes, amongst other changes:- Enforces requirements for authorisation code, token and request object use
- Data Holders MAY support of FAPI 1.0 Final
- Data Holders MAY support of Authorization Code Flow (including **[[PKCE]](#nref-PKCE)** and **[[JARM]](#nref-JARM)**) in conjunction with Hybrid Flow
| July 4th 2022 |
-|[Get Payee Detail V2](#get-payee-detail)|Version 2 of this end point must be made available by affected data holders by July 31st 2022|July 31st 2022|
+|[CX Standards: Joint Accounts](#consumer-experience) | Data holders **MUST** implement the following data standards from 1 July 2022:- Notifications: Alternative notification schedules for joint accounts
- Notifications: Joint account alerts
- Authorisation: Pending status
- Withdrawal: Joint accounts
| July 1st 2022 |
+|[Information Security profile](#security-profile) | FAPI 1.0 adoption is introduced across three phases.
Phase 1: Voluntary FAPI 1.0 support & hygiene enhancements includes, amongst other changes:- Enforces requirements for authorisation code, token and request object use
- Data Holders **MAY** support of FAPI 1.0 Final
- Data Holders **MAY** support of Authorization Code Flow (including **[[PKCE]](#nref-PKCE)** and **[[JARM]](#nref-JARM)**) in conjunction with Hybrid Flow
| July 4th 2022 |
+|[Get Payee Detail V2](#get-payee-detail)|Version 2 of this end point **MUST** be made available by affected data holders by July 31st 2022|July 31st 2022|
|[Data Recipient CDR Arrangement Endpoint](#cdr-arrangement-revocation-end-point) | From July 31st 2022, Data Holders **MUST** revoke consent using "CDR Arrangement JWT" method.
Data Holders **SHOULD** use the "CDR Arrangement JWT" method from March 31st 2022| July 31st 2022 |
-|[Get Payees V2](#get-payees)|Version 2 of this end point must be made available by affected data holders by July 31st 2022|July 31st 2022|
-|[Self-Signed JWT Client Authentication](#self-signed-jwt-client-authentication) | Until July 31st 2022, Data Recipients MUST accept the [Resource Path](#uri-resource-path) for the endpoint and the ```` as a valid audience value. From July 31st 2022, Data Holders MUST use an audience value matching the Resource Path for the endpoint and the Data Recipient MUST verify the audience matches the Resource Path for the endpoint. | July 31st 2022 |
-|[Get Payees V1](#get-payees)|Data holders may obsolete version 1 of this end point from August 31st 2022. Data recipients must upgrade their implementations to use version 2 by this time|August 31st 2022|
-|[Get Payee Detail V1](#get-payee-detail)|Data holders may obsolete version 1 of this end point from August 31st 2022. Data recipients must upgrade their implementations to use version 2 by this time|August 31st 2022|
-|[Information Security profile](#security-profile) | FAPI 1.0 adoption is introduced across three phases.
Phase 2: FAPI 1.0 Final (Baseline & Advanced) includes, amongst other changes:- Enforces additional requirements for authorisation code, token and request object use
- Enforces PAR-only authorisation request data submission
- Refresh token cycling is not permitted
- Data Holders and Data Recipients MUST support FAPI 1.0 Final including **[[RFC9126]](#nref-RFC9126)**, **[[RFC7636]](#nref-RFC7636)** and **[[JARM]](#nref-JARM)**
- Data Holders SHOULD support of Authorization Code Flow in conjunction with Hybrid Flow
| September 16th 2022 |
-|[Get Metrics V3](#get-metrics)|Version 3 of this end point must be made available by affected data holders by October 1st 2022|October 1st 2022|
-|[Standard Error Codes](#error-codes) | Data Holders MAY retire application-specific error codes in favour of standard error codes from November 1st 2022 | November 1st 2022 |
+|[Get Payees V2](#get-payees)|Version 2 of this end point **MUST** be made available by affected data holders by July 31st 2022|July 31st 2022|
+|[Self-Signed JWT Client Authentication](#self-signed-jwt-client-authentication) | Until July 31st 2022, Data Recipients **MUST** accept the [Resource Path](#uri-resource-path) for the endpoint and the ```` as a valid audience value. From July 31st 2022, Data Holders **MUST** use an audience value matching the Resource Path for the endpoint and the Data Recipient **MUST** verify the audience matches the Resource Path for the endpoint. | July 31st 2022 |
+|[Get Payees V1](#get-payees)|Data holders **MAY** obsolete version 1 of this end point from August 31st 2022. Data recipients **MUST** upgrade their implementations to use version 2 by this time|August 31st 2022|
+|[Get Payee Detail V1](#get-payee-detail)|Data holders **MAY** obsolete version 1 of this end point from August 31st 2022. Data recipients **MUST** upgrade their implementations to use version 2 by this time|August 31st 2022|
+|[Information Security profile](#security-profile) | FAPI 1.0 adoption is introduced across three phases.
Phase 2: FAPI 1.0 Final (Baseline & Advanced) includes, amongst other changes:- Enforces additional requirements for authorisation code, token and request object use
- Enforces PAR-only authorisation request data submission
- Refresh token cycling is not permitted
- Data Holders and Data Recipients **MUST** support FAPI 1.0 Final including **[[RFC9126]](#nref-RFC9126)**, **[[RFC7636]](#nref-RFC7636)** and **[[JARM]](#nref-JARM)**
- Data Holders **SHOULD** support of Authorization Code Flow in conjunction with Hybrid Flow
| September 16th 2022 |
+|[Get Metrics V3](#get-metrics)|Version 3 of this end point **MUST** be made available by affected data holders by October 1st 2022|October 1st 2022|
+|[Standard Error Codes](#error-codes) | Data Holders **MAY** retire application-specific error codes in favour of standard error codes from November 1st 2022 | November 1st 2022 |
|[Data Recipient CDR Arrangement Endpoint](#cdr-arrangement-revocation-end-point) | From November 15th 2022, Data Recipients **MUST** validate the `cdr_arrangement_id`, if presented, is the same as the value included in the "CDR Arrangement JWT".| November 15th 2022 |
|[Registration Validation](#registration-validation) | Data Holders **MUST** ignore unsupported authorisation scopes presented in the SSA for the creation and update of client registrations from August 31st 2022 | August 31st 2022 |
-|[Get Account Detail V2](#get-account-detail)|Version 2 of this end point must be made available by affected data holders by November 30th 2022|November 30th 2022|
-|[Get Customer Detail V2](#get-customer-detail)|Version 2 of this end point must be made available by affected data holders by November 30th 2022|November 30th 2022|
-|[Get Product Detail V4](#get-product-detail)|Version 4 of this end point must be made available by affected data holders by November 30th 2022|November 30th 2022|
-|[Get Metrics V2](#get-metrics)|Data holders may obsolete version 2 of this end point from December 5th 2022. Data Holders in the energy sector MAY go live with only Get Metrics v3 support. The CDR Register must upgrade their implementation to use version 3 by this time|December 5th 2022|
-|[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|
-|[Information Security profile](#security-profile) | FAPI 1.0 adoption is introduced across three phases.
Phase 3: Retire Hybrid Flow includes, amongst other changes:- Data Holders MUST support Authorization Code Flow
- Data Holders MAY retire Hybrid Flow
| April 7th 2023 |
+|[Get Account Detail V2](#get-account-detail)|Version 2 of this end point **MUST** be made available by affected data holders by November 30th 2022|November 30th 2022|
+|[Get Customer Detail V2](#get-customer-detail)|Version 2 of this end point **MUST** be made available by affected data holders by November 30th 2022|November 30th 2022|
+|[Get Product Detail V4](#get-product-detail)|Version 4 of this end point **MUST** be made available by affected data holders by November 30th 2022|November 30th 2022|
+|[Get Metrics V2](#get-metrics)|Data holders **MAY** obsolete version 2 of this end point from December 5th 2022. Data Holders in the energy sector **MAY** go live with only Get Metrics v3 support. The CDR Register **MUST** upgrade their implementation to use version 3 by this time|December 5th 2022|
+|[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|
+|[Information Security profile](#security-profile) | FAPI 1.0 adoption is introduced across three phases.
Phase 3: Retire Hybrid Flow includes, amongst other changes:- Data Holders **MUST** support Authorization Code Flow
- Data Holders **MAY** retire Hybrid Flow
| April 7th 2023 |
|[Get Energy Accounts V1](#get-energy-accounts)|- Data Holders **MAY** go-live on November 15 2022 with v1 of this endopint
- Data Holders **MAY** decommission v1 of this endopint as soon v2 is supported
|[Get Energy Account Detail V1](#get-energy-account-detail)|- Data Holders **MAY** go-live on November 15 2022 with v1 of this endopint
- Data Holders **MAY** decommission v1 of this endopint as soon v2 is supported
|[Get Energy Accounts V2](#get-energy-accounts)|Data Holder **MUST** implement v2 of this endpoint by **April 7th 2023**
diff --git a/slate/source/includes/releasenotes/releasenotes.1.20.0.html.md b/slate/source/includes/releasenotes/releasenotes.1.20.0.html.md
index c358adaf..026a41a5 100644
--- a/slate/source/includes/releasenotes/releasenotes.1.20.0.html.md
+++ b/slate/source/includes/releasenotes/releasenotes.1.20.0.html.md
@@ -19,6 +19,7 @@ This release addresses the following minor defects raised on [Standards Staging]
This release addresses the following change requests raised on [Standards Maintenance](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues):
+* [Issue 530: Iteration 12 Holistic Feedback](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/530)
### Decision Proposals
@@ -32,7 +33,7 @@ This release addresses the following Decision Proposals published on [Standards]
|Change|Description|Link|
|------|-----------|----|
-| | | |
+| Cleaned up Future Dated Obligations section | Cleaned up references in the Future Dated Obligation section to consistency use capitalisation for Requirement Levels and remove outdated obligations. Addresses [Issue 530 comment (a)](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/530#issuecomment-1226758035) and [Issue 530 comment (b)](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/530#issuecomment-1238840167) | [Future Dated Obligations](../../#future-dated-obligations) |
## High Level Standards