Adding detail to transaction type definition

[MichaelJBRichards]

TIPS needs to be able to analyse use cases by recipient type as well as by initiator type: for instance, to be able to distinguish readilybetween P2P, P2B and P2G use cases. We therefore propose to add a field to the TransactionType object (spec Section 7.4.18.)

The field should be called recipientType. It should be optional to support backwards compatibility. It should have the same type as the initiatorType field in the current data structure.

[henrka]

By the description, it seems like you would like to distinguish between the type of Payee, as the word recipient is a bit ambiguous and could be recipient of message or recipient of funds.

The existing initiator type is used to determine who initiated the use case, for example it would be the merchant in a Merchant-Initiated Merchant Payment.

In my opinion, the word responder would be more in line with the opposite of the initiator of a use case, if this should be applicable for Payee initiated use cases as well. Hence, responderType is my suggestion.

[henrka]

Another easier alternative is to define your scheme use cases as a subScenario, which is part of TransactionType today. This should make it very easy for TIPS to distinguish between the use cases without changing the API.

[MichaelJBRichards]

Thanks very much for your comments, Henrik. I considered using the subScenario field, as you suggest, but drew back from it for two reasons:

• It's clear from the way in which businesses talk about payment use cases that a use case covers both the type of the debtor and the type of the creditor. People use terms like P2P, P2B, P2G, B2B naturally, and it therefore seemed to me that it would be sensible for our transaction type structure to reflect the same thinking. Now, I appreciate that there's a distinction to be drawn here between the initiator and the debtor - Merchant-initiated Merchant Payments are an obvious example of that - and you're correct to point that out. But, in my opinion, that probably means that we need to distinguish between the initiator field in the transactionType field and the initiatorType field: the initiator is either the payer or the payee, but the type should be the type of the debtor, not the initiator (and we need to add the type of the creditor.)

• I wanted to reserve the subScenario field for other types of definition which we know TIPS is going to need (and which I suspect will also be required for other implementations.) For instance, TIPS will be implementing a bill payment facility. This might be available in a number of different use cases (for instance, P2B, P2G, B2B, B2G) and it seemed to me that this would be an obvious use for the subScenario field across multiple use cases.

I'm perfectly happy with your suggestion for how to name the field

[henrka]

Thanks @MichaelJBRichards for the additional information. Another option which should be easier to understand as it is more consistent with the rest of the API, but at the same time requires some more changes in the implementations, is to change InitiatorType to a PayerType and PayeeType respectively.

Could you please describe the bill payment facitility? At a very high-level (just the wording) I don't really see how the subScenario should be used for that. If this could be used for other implementations as well as you mention, then it could be worthwhile to see if we should standardize it.

[MichaelJBRichards]

PayerType and PayeeType would be fine with me.

On bill payment: if I want to pay, for example, my electricity bill, I make a request to transfer, let's say, 50 EUR to the company's account. For a normal payment, all I want to know is that the recipient has got the funds. But if I'm paying a bill, I want to know more than that: I also want to know that my electricity company has credited my account with them with the funds I paid, and I won't get another request to pay the same bill. So the payee DFSP has to do more than it otherwise would: it has to confirm to the electricity company that the funds have been deposited, receive confirmation from the electricity company that the customer's account has been credited, and send back a confirmation to the payer DFSP and the customer that the electricity company has recorded the payment against the customer's account.

The reason I thought of this as a subScenario was, as I say, because it's a flavour of a number of use cases: C2B, C2G, B2B and B2G can all have bill payment flavours. So if we had a BILLPAY subScenario, we could use that to specify for all those use cases that the extra processing needed to be performed. I have a sequence diagram that describes how the Bill Pay scenario would work, if that would be helpful.

[henrka]

If we would use PayerType and PayeeType, we would also need to include the type (the current TransactionInitiatorType) information in the Party data model, as the initiator of a transaction needs to know which type the Payee is to be able to include that information in the quote. The type TransactionInitiatorType also needs to change name to PartyType instead, as the current name would not make sense anymore.

So the changes in the API would be:
TransactionInitiatorType - Change name to PartyType
Party - Add a new element for the new PartyType
TransactionType - Remove initiatorType, add payerType (of type PartyType), add payeeType (of type PartyType)

The API definition would at least need to be updated in:

• Section 5.3 would need to be updated to explain the new mapping.
• Section 7.4 and 7.5 to update the types
• Section 10 to update the end to end example.

On bill payment: Thanks, sounds like standard bill payment and I know understand why you can't use the subScenario for this in a good way.

[henrka]

On a second thought, the information regarding PayerType and PayeeType would then be repeated in the POST /quotes request in the TransactionType and in Payer and Payee. It should be enough to have the information regarding the type in the Payer and Payee elements, otherwise there is a potential risk that the information is not consistent between them. An example is if TransactionType.payerType is set to CONSUMER, while Payer.type is set to BUSINESS.

The changes in the API would then instead be:
TransactionInitiatorType - Change name to PartyType
Party - Add a new element for the new PartyType
TransactionType - Remove initiatorType

To do the mapping of transaction type to use case, the FSP needs to look at both Payer and Payee elements in the POST /quotes.

[MichaelJBRichards]

I'm confused, Henrik - where is the entity type in Payer and Payee in the POST /quotes request? I agree, if it's there we would merely be introducing new ways of causing errors; but I'm still not sure where I should be looking.

With respect to the TransactionInitiatorType, it seems to me that this item of information is redundant. We already have the Initiator field, which tells us whether the payee or the payer is the initiator. Surely the value of this field enables us to infer the type of the initiator, since we are already holding the types for the payer and the payee. Would you agree?

[henrka]

Your comment seem to align with my last comment (the one starting with "On a second thought..")

The entity type is not there today, why I'm proposing to add it in the in payer and payee:

Party - Add a new element for the new PartyType

And the iniatorType is suggested to be removed:

TransactionType - Remove initiatorType

[mjbrichards]

OK, I think we're agreed

[henrka]

Hi @mjbrichards, this was the CR that I had in mind when we discussed if there were any open issues for TIPS in the SIG meeting 9 February. Is this still required by TIPS?

[mjbrichards]

As far as I'm aware, they do still require it. However, I haven't heard directly from TIPs since December last year. In any case, I'm keen for us to proceed with this addition simply on the basis that it unreasonably restricts implementers if they don't have the extensionList functionality available on all endpoints.

[henrka]

Thanks @mjbrichards, I'm fine with adding these details as we discussed back in 2019.

Anyone else have any comments regarding this? Otherwise we'll try to include this in an upcoming version 2.0 as it is a breaking change.

[millerabel]

Hi @henrik, just curious why adding details is a breaking change? Surely the added details can be safely ignored by participants that don’t expect them? — Miller On Feb 16, 2021, at 4:42 AM, Henrik Karlsson <notifications@github.com> wrote: Thanks @mjbrichards <https://github.com/mjbrichards>, I'm fine with adding these details as we discussed back in 2019. Anyone else have any comments regarding this? Otherwise we'll try to include this in an upcoming version 2.0 as it is a breaking change. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#25 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6OJ6EAAG4FONJG5UTRW73S7JR33ANCNFSM4I7YI4RA>.

[henrka]

Hi @millerabel, sorry I was a bit vague by just saying "added details" in my last comment.

To be more concrete, the mandatory element initiatorType will be removed from the complex type TransactionType. As a mandatory element is removed, this is a breaking change. The information that was previously in the initiatorType will now be part of the Party element instead, so that it is possible to state the type (for example Person, Business, or Government) of both Payer and Payee.

[millerabel]

Thanks @henrik, makes sense. It’s a good change to add this flexibility and is a modest change, but I see it’s a breaking change. Thx

…

-- Miller On Feb 16, 2021, at 10:43 PM, Henrik Karlsson <notifications@github.com> wrote:  Hi @millerabel, sorry I was a bit vague by just saying "added details" in my last comment. To be more concrete, the mandatory element initiatorType will be removed from the complex type TransactionType. As a mandatory element is removed, this is a breaking change. The information that was previously in the initiatorType will now be part of the Party element instead, so that it is possible to state the type (for example Person, Business, or Government) of both Payer and Payee. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[henrka]

I have created a draft pull request (#83) for version 2.0 of the API that contains the changes needed to solve this issue.

[mjbrichards]

Thanks @ehenrka. I've reviewed the pull request and it looks fine to me.

[henrka]

Thanks @mjbrichards!