[cross-border] - KYC data

[adrianhopebailie]

Transactions that cross-borders often have stringent data collection requirements to comply with KYC regulations etc.

One way this might be accommodated is the addition of a new data element in the quote request and response (callback) called Participants.

This would be an ordered list that is added to by each participant and contains data about intermediary and the transfer that it will perform as part of the end-to-end transaction.

E.g:

• Participants:
  • Participant:
    • FspIp: blue-mobile
    • TransferCurrency: USD
    • Fee: USD 5
    • Commission: USD 0
    • Data Requirements: [ full name, national identity number ]
    • Data Encryption Key: gd6g86qwlhjv7tdxkuywef8gfc2welv
  • Participant:
    • FspIp: fxp
    • TransferCurrency: XOF
    • Fee: XOF 5
    • Commission: XOF 0
    • Data Requirements: [ full name, physical address ]
    • Data Encryption Key: 70qw6g86qwlhjv7tdxkuywef8gfc2wel

Data from the payee FSP is encrypted first with the requestor's key and then the payer's key and included in the quote response. It is decrypted by the payer (although still encrypted under the requestor's key) and included in the transfer.

Data from the payer FSP is included in the transfer encrypted under the requestor's key.

Participants can reject the quote if they are unable to provide the data requested or they can reject the transfer if the data provided is insufficient.

This data model needs to be explored more thoroughly including the impact on the message signatures. It's assumed that in a multi-hop transaction each hop will have a different JWS.

[adrianhopebailie]

Based on some discussion with @MichaelJBRichards we think we need to update this to include:

• expiry for each intermediary quote
• only fees and rates charged for intermediaries (not commission or amount)
• amount and fees for payer and payee FSP only
• payee calculates final TX object from this data

TX object will now contain:

• amount for payer to send
• amount for payee to receive
• amount received and sent by each intermediary

Data required by intermediaries from the payee is encrypted with the intermediary key and then the payer key.