Track Account Activity

TxB APIs allow Clients to track real-time ledger activity. Clients use this service to understand what transactions have impacted their TxB account balance today (real-time, intraday) or on previous days (end of day, prior days). Whereas payment status APIs provide interim status updates (e.g., PENDING), ledger activity generally reflects payments which are in a terminal state (e.g., SETTLED).

Step by step guide

Step 1 - Get a list of all referenceNumbers

Our ledger activities APIs provide information on an account or service level. So, our first step is to get a list of the accounts or services ('referenceNumbers') associated with a TxB Client.

GET /v1/reports/transactionReports/reportReferences will return a list of accounts or services that the Client currently uses. It returns 2 referenceNumbers, 1 for a deposit account and 1 for a payments only service.

[
  {
    "referenceNumber": "123456789012",
    "referenceType": "DEPOSITACCOUNT", \\ can be Deposit Account or Payments Service Number
    "isVirtual": false
  },
  {
    "referenceNumber": "123456789011",
    "referenceType": "PAYMENTSONLY", \\ can be Deposit Account or Payments Service Number
    "isVirtual": false
  }
]

Step 2 - Get the transactionReport for the TxB deposit account

GET /v2/reports/transactionReports?referenceNumber='123456789012'&businessDate='10-11-2020&limit=10' returns the full balance info for the account and the first 10 transactions for the requested businessDate:

{
  "asOfDateTime": "2020-10-11T23:52:42.279Z",
  "references": {
    "referenceNumber": "123456789012",  // aka  accountNumber
    "referenceType": "DEPOSITACCOUNT",
    "currency": "USD",
    "jurisdiction": "US",               // Identifies the country of the TxB Branch
    "referenceBank": {...},             // Identifies the BIC, Routing Number of the TxB account
    "isVirtual": false,
    "virtualAccountDetails": {          // shows virtual account hierarchy
     "parentAccountNumber": null,
     "physicalAccountNumber": null
    },

  "balances": [
    {
      "balanceType": "AVAILABLE",
      "startOfDayBalance": 2000,
      "endOfDayBalance": null,
      "currentBalance": 1000
    },
    {
      "balanceType": "LEDGER",
      "startOfDayBalance": 2000,
      "endOfDayBalance": null,
      "currentBalance": 1000
    }
  ],
  "transactions": [
    {
      "postingDate": "2020-10-11T16:52:42.279Z",
      "valueDate": "2020-10-11",
      "amount": 1000.00 ,
      "amountCurrency": "USD"
      "identifiers": {
        "gsUniquePaymentId": "Id_TxB_Created)",
        "paymentEndToEndId": "Id_You_Created"
        ...
      },
      "transactionType": "Outgoing Wire",
      "transactionTypeCode": {
        "domainCode": "PMNT",
        "familyCode": "ICDT",
        "subFamilyCode": "XBCT"
      },
      "linkedRecords": {...}             // E.g., returns link to the original payment
      ...
    }
    ...
  ],
  "hasMore": false
}

Step 3 - Interpret the data & repoll if necessary

Based on the data that we return, you will need to perform some analysis and figure out if there are any additional actions required

• References object

  1. Use this section to understand how this account fits into a broader portfolio of accounts
  2. E.g., if this is a multi-currency account or virtual account, you may need to repeat this query on each virtual account to create a full view of transaction activity

• Balances array

  1. Use this section to understand how much liquidity is available in the account
  2. In this case, the endOfDayBalance is null, which means that the 'books' have not closed on the account for the day. You may want to poll again at the end of the day (e.g., ~8pm EST) when endOfDayBalance is populated
  3. The balances and transactions tie out as expected. balances[0].startOfDay - transactions[0].amount = balances[0].currentBalance

• Transactions array

  1. There is only 1 transaction available for this account on this businessDate. Note that hasMore equals false, so there aren't any additional pages of transactions to pull for this account
  2. Each transaction is uniquely identified by the gsUniquePaymentId (think of this as your transactionId)
  3. In most cases, 1 payment equals 1 transaction, e.g., if I make an outbound wire payment from TxB to another bank, this single wire payment will be reflected as a single transaction
  4. In other cases, 1 payment equals more than 1 transaction, e.g., if that same wire payment is returned by the receiving bank, then you will see two transactions in your account (1 for the payment and 1 for the return)
  5. In yet other cases, more than 1 payment equals 1 transaction, e.g., for bulk-processed payments (e.g., US ACH), all N payments within a payment batch will be treated as a single transaction

For information about account data access for UK open banking, learn more here.