How do I specify an expiry date or a rolling validity date for a policy?

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, see the WhenSpec schema):

"when": {  
  "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, see the ForSpec schema). 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:

curl -X GET https://<domain>.lusid.com/api/api/transactionportfolios/<scope>/<code>/transactions?fromTransactionDate=2021-07-01&toTransactionDate=2021-07-10   

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