Below is a list of steps you would typically need to complete before launching in production with a basic payments use case (Account opening, ACH, and Wires). They all might not be required depending on your use case and partner bank.

​
Pre-launch Checklist

  • Getting started

  • Share funds flow with bank partner for review/approval

    • Document how money will flow in and out of your partner bank(s) for your use case(s), including details such as the types of payment used and any external partners being utilized. Any changes to the flow during implementation will need to be documented for your bank partners’ records.

  • Account Opening

    • Understand the sequence of API calls required to create an account as outlined in our account creation guide.

    • KYC/KYB

      • Select a KYC/KYB provider and align with your bank partner on any KYC/KYB requirements. It is critical that you receive bank approval on this piece.
      • If you are leveraging a Treasury Prime partner integration for KYC/KYB, understand what fields are required when creating the person, business, and account applications.
      • If you are leveraging an independent KYC/KYB provider, confirm with your bank partner if the third-party KYC endpoint will need to be used.
      • Align with your bank partner on how to handle manual review outcomes from KYC/KYB evaluations.

  • Account Management

    • Collaborate with your bank partner to establish a bank-approved process for locking accounts and closing accounts.
    • Determine if you are leveraging Treasury Prime’s statements endpoint or building your own statements. Note: our statements endpoint generates statements in a format that is pre-approved by our bank partners. To the extent you are building your own statements, you will need to obtain bank approval for the format and relevant disclosures.
    • If you are planning to offer interest payments to your end-users, please work directly with your bank partner.

  • Payments

    • ACH

      • Understand the lifecycle of originating an ACH, outlined in our ACH guide.

        • Each of our partner banks has its own ACH windows throughout the day when ACHs are processed in batches. Please confirm these windows with your partner bank to better understand when you can expect originated ACHs to settle.
        • Your partner bank will implement ACH holds (if you are on the FBO model). Please confirm these hold times with your partner bank to understand when funds will be made available to your end users.

      • To expedite testing, leverage our ACH simulations in sandbox.

    • Wires

      • We generally process wires every few minutes, but please confirm with your partner bank. Each bank might have different wire processing hours during the day. If a wire is submitted outside of these hours, the wire’s status will be in pending until the next processing window opens.
      • Please leverage our Wire simulations in sandbox for testing.

    • Cards

      • First, determine the types of card products you will be leveraging based on your use case and timelines: virtual, physical, and/or digital wallets. Virtual and physical cards can be implemented relatively quickly, while digital wallets can take longer due to the approvals needed from the bank, the network, and Apple/Google. Most customers will launch with virtual/physical cards to start and add digital wallets at a later point in time.

      • Card art templates will be shared once you kick off with your partner bank. It is important to return completed card art assets as quickly as possible, as this is what kick-starts the card implementation process. Review/approval of your card assets will be required by: your bank, the network, and/or the card printer as applicable.

      • Managing risk

      • Please leverage our Card simulations in sandbox for testing.

    • Book Transfers

      • Note that book transfers can be performed between ledger and core accounts. A common example of this is interest payments, where funds used for interest payments are book transferred from an on-core operating account into a sub-ledger account.

  • Webhooks

    • We strongly recommend leveraging webhooks vs. polling our API for statuses to avoid any potential performance issues at scale
    • If a valid HTTP response is not received, the API will retry up to 15 times on an exponential backoff schedule. A 200 or 202 response code is expected.
    • A webhook response should only be determined by your server’s ability to receive the incoming notification. Any backend processing or handling of the actual event should not factor into the returned HTTP response.

  • Storage & Logging

    • Some banks may require regular reporting on activity, so please work with your bank partner to ensure you have the correct data stored/readily available
    • Have TP identifiers ready for troubleshooting with your bank partner and/or our Support team

  • Partners

    • Many customers leverage 3rd party vendors that Treasury Prime has an existing partnership with. Check out our partner marketplace for more information on our partners.

  • Compliance toolkit review

    • While you will work directly with your bank partner on any due diligence and compliance requirements, feel free to use our compliance toolkit for guidance. Note: some sections are gated behind permissions so you will need to request access.

  • Transaction Monitoring

    • Work with your bank partner to determine the best transaction monitoring solution for you
    • Your bank partner will provide guidance on the transaction monitoring rules to implement and establish relevant roles and responsibilities for each phase of the transaction monitoring process

  • Request Production Access from your partner bank. You will need to ensure:

    • Bank MSA is fully executed
    • Bank due diligence has been approved
    • Any other requirements provided by your bank partner have been completed

  • Subscribe to our status page

  • Support portal access: We strongly recommend utilizing our support portal for increased visibility across your team and easier case management.

  • Provide contact information for notifications:

    • Escalation contact: refers to the designated point of contact or team responsible for handling issues that require escalation beyond the initial support level.
    • Dispute contact: refers to the designated contact or team responsible for managing and resolving disputes between you and your customers.
    • Outage notification contact: refers to the method or system used to inform you about service disruptions, system failures, or downtime affecting a product, service, or network.