Scripted trade does not generate past cashflows when value date is strictly after the last settlement date

[quantthingy]

true

how to reproduce:

• change value date to any date strictly after after the last settlement date

result:

• cashflow table is empty

expected result:

• return the past cash flows

I can provide an example if needed.

[pcaspers]

Hi! Just to be sure - are you setting

• includePastCashflows to true in the cashflow analytic settings (in ore.xml) and
• IncludePastCashflows to true in the EngineParameters of the scripted trade engine configuration

Both is necessary to get past cashflows in the report. The first flag controls the general filter on past cashflows and the second flag enables past cashflow info generation for scripted trades.

If you are using both flags already, could you kindly post an example to reproduce the issue? Thanks!

[quantthingy]

Both flags are included.
Provided an example based on Example 52 from the release, using 1.8.12.1 version

Input and Output files are included.

Thanks for looking into it.

Archive.zip

[pcaspers]

The trade is considered "expired" in this case and therefore excluded from all reports.

I'll change the behavior so that the trade never expires if IncludePastCashflows is active for scripted trades. This change should appear on the master branch soon.

Please note that this change won't change the behavior of non-scripted trades which will still be excluded from the reporting if they are expired.

[pcaspers]

A few more notes:

There is a typo in the parameter name in ore.xml, it should be

    <Analytic type="cashflow">
...
      <Parameter name="includePastCashflows">true</Parameter>
    </Analytic>

The example script does not produce a cashflow. I changed

        <Number>
          <Name>GuaranteedFixings</Name>
          <Value>0</Value>
        </Number>

to get a flow for testing.

[quantthingy]

Thanks for the change.

Some brainstorming:

• the current behavior is inconsistent as Autocallable are generating Cashflow information between an early knock-out and the last potential settlement date. Maybe the script language could be enhanced with an "Expired" Keyword?
• there is a business case for a cashflows report including expired trades, targeted to back-office reconciliation (checking the counterparty settled the correct amount for derivatives trades)

[pcaspers]

• Autocallabe: It should not. Can you give an example?
• Use case reconciliation: yes, agreed.

[quantthingy]

. Autocallable: I was referring to any Scripted trade with a Knock-out barrier. From a financial point of view, the expiry date is the Knock-Out date and not the the last potential Settlement date. This is the same logic for any barrier instrument.

in ored/portfolio/autocallable_01.hpp , the Trade Autocallable_01 is such an example

[pcaspers]

Yes, but if the autocallable is knocked out on a date d <= asof then it should not generate non-zero cf info after d?

…

On Wed, 10 Jul 2024 at 09:11, Julien Musset ***@***.***> wrote: . Autocallable: I was referring to any Scripted trade with a Knock-out barrier. From a financial point of view, the expiry date is the Knock-Out date and not the the last potential Settlement date. This is the same logic for any barrier instrument. in ored/portfolio/autocallable_01.hpp , the Trade Autocallable_01 is such an example — Reply to this email directly, view it on GitHub <#253 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAT4HLMP5DSJUZRVRUEJMODZLTNDNAVCNFSM6AAAAABKQECXHGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJZG4ZDQOBVGY> . You are receiving this because you commented.Message ID: ***@***.***>

[quantthingy]

Agree. To be precise:

Assuming an autocallable with 3 autocall observation dates: 1 Jan 2023, 1 Feb 2022, 1 March 2022
If the autocall happened on 1 Feb 2022 (and therefore no cashflow on 1 March 2022), then I got the following in my test:

case 1: Value date on 15 Feb 2022: historical cashflow table generated at the instrument level
case 2: Value date on 15 Mach 2022: no historical cashflow table generated at the instrument level

Your solution will solve this inconsistency.

(apology dont have an example to share, as all the test were in c++)

[pcaspers]

ok sounds good, we'll try to push out an update on master so that you can test the fix

[quantthingy]

Hi, Any update on this request?

[pcaspers]

apologies - we did the code changes internally, but they are not yet published on github, this might take until the next full release (planned for March 2025)