Tag each payment with the corresponding payment time

[matteolimberto-da]

This is a small but breaking change to the Lifecycle Result.

The pending items, which included the asset and quantity to be settled, now additionally include the corresponding payment time.

There are a couple of reasons why I think this makes sense:

• we can model some financial instruments (e.g. bonds, swaps) without storing any tree

  • we just generate the tree on-the-fly during lifecycling and chop off the payments that have already been made

• it decouples payment granularity vs lifecycle granularity

  • in the natural gas use-case, this was used to e.g. run the lifecycling once a day but get assets corresponding to an hourly gas flow

• It is a building block if we want the LC function to return all known payments, rather than just the payments falling before or at today

Happy to hear your feedback on this.

[lucianojoublanc-da]

• It is a building block if we want the LC function to return all known payments,

How do you envision this working for conditional branches?

• generate the tree on-the-fly during lifecycling and chop off the payments that have already been made

I'm not sure I understand why you need the dates for this?

[matteolimberto-da]

• It is a building block if we want the LC function to return all known payments,

How do you envision this working for conditional branches?

Are you referring here to sub-trees of a Cond node or to sub-trees of When pred ?

In the first case, if we acquire the Cond node then we are guaranteed to immediately acquire only one of the two sub-trees.

In the second case, any payment falling after a When pred c would be considered as unknown.

• generate the tree on-the-fly during lifecycling and chop off the payments that have already been made

I'm not sure I understand why you need the dates for this?

You are right that it is not needed for a bond or a swap, where we could effectively just generate the "remaining claim" from a strongly-typed contract. It just felt easier in my mind to avoid modifying the tree and just act on pending payments, but it is indeed not a constraint.

[lucianojoublanc-da]

In the second case, any payment falling after a When pred c would be considered as unknown.

Ok, I think I misunderstood what you meant by 'known'. I didn't quite understand how you could return "all known payments" in the future, if there was an Or or a Anytime branch, for instance. So known = past.

[matteolimberto-da]

In the second case, any payment falling after a When pred c would be considered as unknown.

Ok, I think I misunderstood what you meant by 'known'. I didn't quite understand how you could return "all ~known~ payments" in the future, if there was an Or or a Anytime branch, for instance. So known = past.

Indeed, I should have been more precise. I meant "return all payments that are known today".