Understanding Transaction Date and Time

Varied Silvergate accounts will show transaction records in API history responses from a variety of payment channels, some with their own native time zones. We also recognize that our customers are performing transaction attribution from around the globe. To assist, this document is meant to exhaustively communicate important format and time zone details for fields contained in our API responses.

Formats and Timezones

For all fields in endpoint Responses and Params labeled date-time, the format is RFC 3339, which has the format of YYYY-MM-DD HH:MM:SS.mm. For example, "2022-08-29 20:10:46.864".

Some fields do not populate a time but will still adhere to the format. For instance, fields like effective_date in GET history could show, "2022-08-10T00:00:00", where there is no time component. However a date will always be relative to a time zone; and for fields like effective_date the date will always be a banking day, specifically based on Silvergate's headquarters in Pacific Time. In other words, the end of one day and the beginning of the next in fields with no time component still relies on a time zone.

A final important callout: When tying together wire data from GET history and GET payments, a payment could show up in a different date range for GET history than for GET payments. This is because GET history is querying when a payment posts to an account, whereas GET payments is querying the date when an inbound payment arrived at Silvergate or an outbound payment was initiated (the entry_date).

Date-Time Field Compilation by Endpoint:

  • ACCOUNT

    • GET Balance

      • account_opened_date

        • The date on which the account was opened

        • timezone: Pacific

      • last_statement_date

        • The date of the most recent statement

        • timezone: Pacific

    • GET cash manager account balance

      • opened_date

        • The date on which the account was opened

        • timezone: Pacific

    • GET History

      • begin_date

        • Optional, the beginning date range for history query; a
          blank value will default to current day. Note- date
          fields ignored when is-real-time=true. This parameter is
          querying effective_date

        • timezone: Pacific

      • end_date

        • Optional, the ending date range for the history query; a
          blank value will default to current day. Note- date
          fields ignored when is-real-time = true. This parameter
          is querying effective_date

        • timezone: Pacific

      • transaction_description

        • String, The primary description line

        • See our SEN data attribution
          blog

          to learn about possible included string date-time
          possible in this field, based on transaction type

      • effective_date

        • A transaction's effective date, which is always a
          banking day. There is no time component of the
          effective_date

        • timezone: Pacific

      • SEN_TRANSFER_RESPONSE (object)

        • timestamp (sub-object field)

          • String, Date and time when a transaction took

          • timezone: Pacific

  • FX

    • FX RFQ

      • quote_expiration

        • The timestamp indicating when the quote will expire.

        • timezone: UTC

      • value_date

        • Date on which funds are expected to be transferred to
          the beneficiary. There is no time component of the
          value_date

        • timezone: Pacific

    • FX Execute market order

      • value_date

        • Date on which funds are expected to be transferred to
          the beneficiary. There is no time component of the
          value_date

        • timezone: Pacific

    • FX Internal RFQ

      • quote_expiration

        • The timestamp indicating when the quote will expire.

        • timezone: UTC

      • value_date

        • Date on which funds are expected to be transferred to
          the beneficiary. There is no time component of the
          value_date

        • timezone: Pacific

    • FX Execute internal market order

      • value_date

        • Date on which funds are expected to be transferred to
          the beneficiary. There is no time component of the
          value_date

        • timezone: Pacific

    • GET Trades

      • begin_date

        • Optional, the beginning date range for history query; a
          blank value will default to current day. Note -- date
          fields ignored when is-real-time = true.

        • timezone: Pacific

      • end_date

        • Optional, the ending date range for history query; a
          blank value will default to current day. Note -- date
          fields ignored when is-real-time = true.

        • timezone: Pacific

      • trade_date

        • Date on which the trade was executed, with Pacific Time
          timestamp.

        • timezone: Pacific

      • value_date

        • Date on which funds are expected to be transferred to
          the beneficiary. There is no time component of the
          value_date

        • timezone: Pacific

    • EXECUTE FX (or INTERNAL) Trade

      • value_date

        • Date on which funds are expected to be transferred to
          the beneficiary. There is no time component of the
          value_date

        • timezone: Pacific

    • GET TRADE

      • trade_date

        • Date on which the trade was executed, with Pacific Time
          timestamp.

        • timezone: Pacific

      • value_date

        • Date on which funds are expected to be transferred to
          the beneficiary. There is no time component of the
          value_date

        • timezone: Pacific

    • CREATE FX PAYMENT/ ADHOC PAYMENT

      • payment_timestamp

        • Most recent timestamp when the status of the payment
          changed

        • timezone: UTC

  • PAYMENT

    • GET Payments

      • begin_date

        • Required, the begin date range for payments query, which
          queries the Response entry_date. Timestamp does not
          factor.

        • timezone: Pacific

        • A reminder that GET payments is querying the date when
          an inbound payment arrived at Silvergate or an outbound
          payment was initiated, whereas GET history is querying
          when a payment posts to an account.

      • end_date

        • Optional, the ending date range for the payments query,
          which queries the Response entry_date. A blank value
          will default to current day. "End_date" must be within
          32 days of "begin_date" and timestamp does not factor.

        • timezone: Pacific

        • A reminder that GET payments is querying the date when
          an inbound payment arrived at Silvergate or an outbound
          payment was initiated, whereas GET history is querying
          when a payment posts to an account.

    • GET Payment

      • payment_date

        • The date on which the payment is processed

        • timezone: Pacific

      • entry_date

        • The date the payment is first submitted into the
          payments system.

        • timezone: Pacific

      • completion_date

        • The date of posting to the Silvergate bank account.

        • timezone: Pacific

      • cancel_date

        • The cancelation date, if applicable

        • timezone: Pacific

      • time_stamp

        • The timestamp marks the last action on a payment and is
          critical as an input for POST and PATCH payment.

        • timezone: UTC

    • GET Payment Instructions

      • value_date

        • The date on which funds are expected to be transferred
          to the beneficiary. There is no time component of the
          value_date.

        • timezone: Pacific