You can specify an expiry date for a policy. When the policy expires, access to features or data is denied.
Note: If you do not specify an expiry date, a policy expires on 31 December 9999 (that is, effectively never).
You can also specify different kinds of rolling validity date for a data policy. Depending on the specification, the policy is only effective before or after that date, relative to a point in time.
Specifying an expiry date for a policy
You can specify a Deactivation date when you create either a feature policy or a data policy in the LUSID web app:
The expiry date is recorded in the JSON document using the when keyword (for more information on this, search the Access API documentation for WhenSpec):
"activate": "2021-02-01T23:00:00.0000000+00:00",
"deactivate": "2022-02-01T23:59:59.9999999+00:00"
}
Specifying a rolling validity date for a data policy
You can specify a rolling validity date for a data policy (not a feature policy). This means the policy only takes effect a set date before or after a relative point in time, such as ‘now’ or the ‘first business day of the month’.
You can use this feature to restrict access to the latest data, or conversely to only allow access to the latest data. For example, the following policy allows a portfolio manager to see transactions that are 7 or more days old, but prevents access to the most recent transactions recorded in the last 6 days:
"description": "Allow access to portfolio data recorded 7 or more days ago",
"applications": [
"LUSID
],
"grant": "Allow",
"selectors": [
{
"idSelectorDefinition": {
"identifier": {
"code": "*",
"scope": "*"
},
"actions": [
{
"scope": "default",
"activity": "Any",
"entity": "Portfolio"
}
]
}
}
],
"for": [
{
"effectiveDateRelative": {
"date": "Now",
"adjustment": -7,
"unit": "Day",
"relativeToDateTime": "BeforeOrOn"
}
}
],
"when": {
"activate": "2021-02-01T23:00:00.0000000+00:00",
"deactivate": "2022-02-01T23:59:59.9999999+00:00"
}
}
The for keyword in the JSON document describes this behavior (for more information on this, search the Access API documentation for ForSpec). Changing relativeToDateTime to AfterOrOn flips this policy to only allowing access to the most recent transactions recorded in the last 7 days.
Note that whenever a user makes an API request to get a set of transactions, a ‘from’ and ‘to’ date are specified. By default, the ‘from’ date is the date the portfolio was created, and the ‘to’ date is the datetime of the API request. A user can override this to return a more limited set of transactions using the fromTransactionDate and toTransactionDate parameters, for example:
Note that if any part of the period requested falls outside the validity date of the policy, then no transactions are returned, even those nominally within the date. For example, imagine the following scenario:
- Policy: Allow access to portfolio data recorded 7 or more days ago
- Date of API request: 10 August 2021
- XYZ transaction recorded: 2 August 2021
Nominally, the XYZ transaction is 8 days old, and the portfolio manager is entitled to see it. But whether they actually do or not depends on the ‘from’ and ‘to’ dates in their API request:
| API request | Transaction returned? | Explanation |
| From: 2 July 2021 To: 2 August 2021 |
YES | Period requested falls wholly within the validity date of the policy |
| From: 2 July 2021 To: 3 August 2021 |
NO (403 Forbidden) | Period requested falls partly outside (by one day) the validity date of the policy |