Internal Transactions

An internal transaction is one where both the originator and the beneficiary of the transaction are account holding parties. This means, they both hold accounts with you, the customer of our solution, and therefore the transaction does not "leave" your business.

Our solution is typically used for a transaction between an account holding party and a counterparty (a third party/non-account holding party). For incoming transactions, the counterparty is the originator and the account holding party is the beneficiary,

For internal transactions we have two account holding parties. To ensure that the rules and AI models track the correct volumes for both account holding parties, the transaction should be sent to the gateway twice. Once with the originator as the account holding party and once with the beneficiary as the account holding party.

In each transaction, the other account holding party's details can be populated in the "counterpartyData" object to ensure this party's details are visible in the Case Manager to give operators the necessary context when reviewing cases.

In addition, the "executionScopes" field should be provided within these transactions and set to "INTERNAL". This will allow you to specify within the rule configuration whether a rule applies to these internal transactions and create internal transaction-specific rules.

The two transactions should not share same transactionID, we recommend add suffix, e.g. _1; see example below.

Example

The following is an example of an internal transaction sent to the gateway twice, each with the originator and beneficiary as the account holding party respectively. In this example, Paris Saint-Germain FC and FC Barcelona are both our customer (i.e. "account holding parties") and the transaction is going from Paris Saint-Germain FC to FC Barcelona.

Note the inclusion of the "executionScopes" field and the switching of the "accountHoldingPartyData" and "counterpartyData" objects for each.

Transaction 1

    {
        "tenantProcessingTimestamp": "2022-02-17T14:51:53.000Z",
        "tenantTransactionId": "internal_transaction_1",
        "fundsOriginator": {
            "accountNumber": "FR33088651602666640607",
            "holder": "Paris Saint-Germain FC",
            "bankIdentifier": "SSKMFRMM"
        },
        "fundsBeneficiary": {
            "accountNumber": "FR274231823176413385",
            "holder": "FC Barcelona",
            "bankIdentifier": "SSKMFRMM"
        },
        "accountHoldingParty": "FUNDS_ORIGINATOR",
        "settledAmount": 250000000,
        "settledCurrency": "EUR",
        "usage": "Neymar Transfer",
        "executionScopes": "INTERNAL"
    }

Transaction 2

    {
        "tenantProcessingTimestamp": "2022-02-17T14:51:53.000Z",
        "tenantTransactionId": "internal_transaction_2",
        "fundsOriginator": {
            "accountNumber": "FR33088651602666640607",
            "holder": "Paris Saint-Germain FC",
            "bankIdentifier": "SSKMFRMM"
        },
        "fundsBeneficiary": {
            "accountNumber": "FR274231823176413385",
            "holder": "FC Barcelona",
            "bankIdentifier": "SSKMFRMM"
        },
        "accountHoldingParty": "FUNDS_BENEFICIARY",
        "settledAmount": 250000000,
        "settledCurrency": "EUR",
        "usage": "Neymar Transfer",
        "executionScopes": "INTERNAL"
    }

In summary

• Send internal transactions in twice - once with the originator as the account holding party and once with the beneficiary as the account holding party
• Include the "accountHoldingPartyData" and "counterpartyData" as normal and switch these for each transaction to correspond with the correct account holding party and counterparty
• Include "executionScopes": "INTERNAL" within the transaction
• Within rules, you can specify whether a rule should exclude internal transactions or apply specifically to them