Internal transactions

An internal transaction is one where both the originator and the beneficiary are your own account-holding parties (AHPs). The payment does not “leave” your institution.

Most flows involve one AHP + one Counterparty (external party). Internal payments are the exception: two AHPs.

Rules, limits, and AI models track volumes per AHP. To ensure both parties’ profiles and rule counters are updated correctly, submit two events:

1. Event A: accountHoldingParty = FUNDS_ORIGINATOR

2. Event B: accountHoldingParty = FUNDS_BENEFICIARY

Both events describe the same transfer, but each one treats a different party as your Customer.

Include executionScopes: "INTERNAL" so you can target or exclude these events in rule configuration.

Mapping guidance

• Use the same business facts (amount, currency, timestamp, originator/beneficiary details).

• Do not reuse the same tenantTransactionId. Add a suffix (e.g., _1, _2) or another unique token.

• In each event:

  • Populate the current customer’s details under accountHoldingPartyData.

  • Populate the other party’s details under counterpartyData.

• Keep the payment direction the same (originator → beneficiary). Only flip accountHoldingParty between events.

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, both Paris Saint-Germain FC and FC Barcelona are your customers (AHPs). The transfer goes from PSG to FC Barcelona.

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

Transaction 1: Customer is the originator

    {
        "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: Customer is the beneficiary

    {
        "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"
    }

Try it out here

In summary

• Send two events per internal payment (originator-as-AHP and beneficiary-as-AHP)

• Use unique tenantTransactionId for each event (e.g., _1, _2)

• Include executionScopes: "INTERNAL" within the transaction

• Swap accountHoldingPartyData and counterpartyData accordingly.

• Keep direction (fundsOriginator → fundsBeneficiary) consistent in both.