API App - Release to Production

API Application Guide for Releasing an Application to Production

Checklist

  • Diagram of Flow of Funds

  • Review functional app / integration on Sandbox (https://sandbox.xtrm.com)

  • Customer’s Enrollment/Sign up process (Remitter & Beneficiary)

    • List any due diligence processes

    • What remitter and/or beneficiary details are collected upon initial sign up

    • Each remitter must be onboarded separately

      • Ensure Master admin or remitter accounts is proper person – signatory authority

      • Completion of Advanced Profile application for remitters

  • XTRM Terms & Conditions linked

  • Bank link walkthrough of integration

  • Transfer walkthrough of integration

  • Foreign exchange rates agreement in place if utilized

  • Help/Support plan of integrator/managing account or remitter

    • Integrator and/or managing account needs to be primary support

  • Integrator to register on production server (https://www.xtrm.com)

  • Obtain API keys from production  account

    • White list IP on production credentials

    • Run test transactions on production server 





The Checklist Explained

Actors & Roles

Keeping the actors and roles clear is critical as to who is doing what for whom.


Ultimate Remitter

The ultimate remitter is the source of funds, the company initiating the payment. A company may make payments on its own behalf, or these payments may be made by a third party (a managing company).

Remitter

The remitter is the company making the payment via XTRM, either on its own behalf (in which case they are also the ultimate remitter), or on behalf of another company.

Beneficiary

The beneficiary is the entity (which may be a company or individual) receiving the funds.

XTRM

XTRM holds funds on behalf of the ultimate remitter(s) as a third-party financial processor. XTRM takes on responsibility for KYC, KYB, money-laundering prevention, regulatory compliance and tax reporting compliance. Once payments are processed by XTRM, the funds belong to the beneficiary; the payment is completed. In many cases, XTRM is then holding the funds for the beneficiary.

Diagram of Flow of Funds

A diagram of how monies move from party to party is a useful explanatory tool to help regulators understand the money flow.

For compliance purposes, the flow of money must be clear as to the source of the funds (the ultimate remitter), and the entity receiving those funds (the beneficiary). Companies that manage payment plans for other remitters cannot hold funds for their clients unless they have regulatory permission (as a third party payor such as XTRM). 

If company A (AliceCo)  is making payments on behalf of company B (BobGmbH) to a third party C (Carol), to remain compliant funds must always be in possession of BobGmbH, even though AliceCo has permission to take actions on behalf of BobGmbH. In the XTRM ecosystem, this means that AliceCo is a managing company. Both AliceCo and BobGmbH must be onboarded as remitters, and payments made on behalf of BobGmbH must originate from wallets belonging to BobGmbH (which AliceCo has permission access).

To remain in compliance, AliceCo must not make payments on behalf of BobGmbH from wallets owned by AliceCo, nor may AliceCo receive monies from BobGmbH for dispersal to other entities.

To remain in compliance, funds in wallets owned by BobGmbH must originate from BobGmbH (AliceCo may not transfer funds into BobGmbH’s wallets unless AliceCo is making a payment to BobGmbH). Even in the situation where AliceCo is making a payment to BobGmbH, this may be sufficient to draw regulator attention simply because it looks like commingling of funds. A clear, well-laid out flow diagram of funds, showing where funds originate and how they are dispersed can go a long way towards reassuring regulators that all transactions are compliant and transparent.

Funding for BobGmbH’s wallets must originate from BobGmbH, typically as an ACH, SWIFT, or check.


Each Ultimate Remitter must be onboarded separately

To remain compliant, each remitter is onboarded separately. XTRM manages this a little differently than some other companies, where companies and conglomerates may have multiple accounts. XTRM simplifies this process by requiring that a single company have a single account, regardless of geography or separation of business units. This allows a company, once onboarded, to enable XTRM payments for any part of its business with minimal regulatory fuss. To maintain regional and business separation of funds, XTRM supports fine-grained permissions for administrators. A particular administrator might have access only to regional or sub-regional wallets, or have access to wallets with funds for specific purposes. 

At first glance, this might seem like a complication, but regulators require information about the ultimate source of funds (the parent company). Onboarding the parent company, and establishing wallets and administrators restricted along regional or business boundaries means more transparency for regulators, which in turn keeps them happy (and far, far away).


Completion of Advanced Profile application

Onboarding happens in several steps, and the details are beyond the scope of this document. The general process is that companies supply information about themselves (tax documents, bank accounts, etc.) and as they do so, they complete the advanced profile for themselves. The more information XTRM has about a company, the more complete the profile, and the more latitude XTRM can extend (in terms of  limits on amount of funds transferred, the number of transfers permitted per day and per week, and overall velocity limits). XTRM has a document discussing the standard limits. 

If these limits, even with a fully complete profile, are insufficient, please contact your partner manager or XTRM support. We can increase these limits to support your requirements.

Due diligence / KYC / KYB performed

To comply with XTRM’s own regulatory burden, XTRM performs Know-Your-Customer (KYC) and Know-Your-Business checks. This is XTRM’s responsibility, and generally takes several business days when onboarding a new remitter. XTRM will contact managing companies should any issues arise (it is unusual for this to happen; most companies can be onboarded without difficulty). Likewise, XTRM needs to know what information you’re handling (and perhaps reduce your compliance burden further).


https://xtrm.freshdesk.com/en/support/solutions/articles/4000159535-onboard001-onboarding-your-company-overview



Review functional app / integration on Sandbox

Development and testing occur in a dedicated sandbox environment. This environment runs the same software as XTRM’s production systems, except that funds are not actual funds, and no actual financial connections (no actual banks are linked, only test accounts) are maintained. XTRM will place money in test accounts, as needed for development and testing of applications.

Before XTRM enables any accounts on production, XTRM requests an application walk-through on the live sandbox (to see the API used), to ensure the application is both secure and compliant.

Monitor API requests (real time)

During this test, XTRM will monitor the application in the sandbox and watch the API calls live.

Enroll/Sign up process

Collected Information

XTRM collects as little personally identifiable information (PII) as possible, as needed, and in many cases can remove significant quantities of PII from remitter’s systems.

Due diligence

Knowing what due diligence has already been completed by our remitters can speed XTRM’s own due diligence process. 

The Master Administrator

To properly assume regulatory and financial compliance, XTRM needs the Master Administrator for every remitter to have signatory authority over the funds held for the remitter by XTRM. The Chief Financial Officer (CFO) is often the right person, but not always. Although the CFO or a similar corporate officer may have the right authority, they do not always have the time or technical expertise to administer the account. To make administration simpler, XTRM has three levels of administration. More detail is available at https://xtrm.freshdesk.com/en/support/solutions/articles/4000166929-compliance011-understanding-the-role-of-a-master-admin

https://xtrm.freshdesk.com/en/support/solutions/articles/4000156710-security008-companies-admin-roles-and-access-levels

The Master Administrator

This is the person with signatory authority, and the sole person able to delete other administrators. Each account has exactly one master administrator, and the master administrator’s personal profile must be complete for the account profile to be complete. All compliance documents must be uploaded by the master administrator.

Managing Administrators

Managing administrators have full control, and may create and suspend other administrators (although not the master administrator). They can set permissions for administrators to limit their access to funds and wallets. Although managing administrators can suspend administrator accounts (effectively removing all permissions and access), they cannot delete other administrator accounts. Deletion is reserved for the master administrator account.

Standard Administrators (Regular Administrators)

Regular administrators have more limited access, and are typically administering programs or regions, with their access limited to the relevant set of wallets and banks. XTRM’s permissions are very fine-grained so that a managing administrator can give an administrator exactly the capability that individual requires, and no more.