Universal api dataexchangestandards_remittanceindustry

RemitBroker
A universal REST API and encrypted JSON data exchange platform for Remittance
Service Providers
ABOUT THE AUTHOR
The author is a technologist with over two decades of experience in the architecture, design and
implementation of enterprise applications. For the last five years he has been working with and
has been instrumental in redefining the enterprise architecture and application stack for a
leading global remittance services company with an agent network spread across 125 countries.
© 2017. All rights reserved by the author.
The information, views and ideas set out in this article are those of the author and do not
necessarily reflect the official opinion of the company he works for.
Reproduction is authorized provided the author and source are acknowledged.
First Published: January 2017

of 23
CONTENTS
1 Introduction .............................................................................................................................. 3
1.1 Money Transfer Services ................................................................................................. 3
1.2 Remittance Service Providers.......................................................................................... 3
1.3 Integration Challenges ..................................................................................................... 4
2 Systems Integration................................................................................................................. 4
2.1 Current Approach............................................................................................................. 4
2.2 Limitations of the Current Approach ................................................................................ 5
3 The Universal API Solution ..................................................................................................... 6
3.1 Proposed Approach ......................................................................................................... 6
3.2 Data Exchange Sequences ............................................................................................. 8
3.3 REST Interfaces............................................................................................................. 13
3.4 Data Exchange Message Structures ............................................................................. 14
3.5 Integrity, Confidentiality and Non-Repudiation .............................................................. 14
4 Technology Stack .................................................................................................................. 15
5 Challenges............................................................................................................................. 17
6 Conclusion ............................................................................................................................. 17
7 Glossary................................................................................................................................. 18
8 Appendix A: API Interfaces ................................................................................................... 19
9 Appendix B: Messages and Data Structures ........................................................................ 20
9.1 Transaction Request ...................................................................................................... 20
9.2 FX Rate Update.............................................................................................................. 21
9.3 Rule Data........................................................................................................................ 22
9.4 Response Message ....................................................................................................... 22

of 23
1 INTRODUCTION
1.1 MONEY TRANSFER SERVICES
Money Transfer, as the name suggests, is a financial service that allows customers to transfer
money from one entity to another. This has many forms, but can be broadly divided into two
categories: Electronic Funds Transfer (EFT) and Remittance.
EFT is the transfer of money using a cashless mode, either within a single financial institution or
across multiple institutions. The transfer can be directly from one bank account to another or
from a credit or debit card to a bank account. Banking systems use well-defined and universally
accepted protocols such as SWIFT, RTGS and IMPS to carry out these transfers.
Remittance is the transfer of money in which there is a cash component on at least one side of
the transaction. Thus, remittance transactions can be cash to cash, cash to bank account, bank
account to cash or credit or debit card to cash. Remittance systems do not have a standardized
protocol and each remittance service provider uses independently designed processes and
protocols. This is the primary problem that the universal API and data exchange platform
proposed in this paper seeks to resolve.
An important consideration is the increasing acceptance of mobile wallets as an alternative to
cash. In a remittance transaction, cash on either side can easily be replaced by a mobile wallet.
Thus, remittance transactions can be mobile wallet to mobile wallet, cash to mobile wallet, bank
account to mobile wallet, credit or debit card to mobile wallet and so on.
1.2 REMITTANCE SERVICE PROVIDERS
Remittance Service Providers (hereafter referred to as remitters) are businesses that provide
services associated with remittances. The remittance business model comprises of two primary
functions, send and payout.
On the send side of the transaction, remitters collect money from the sending customer and on
the payout side of the transactions, remitters pay out money to the beneficiary customer.
Countries usually predominantly send or pay out depending on their demographics and
regulatory restrictions, although some countries may both send and pay out. Accordingly,
remitters in every country focus on the send or pay out of transactions.
Remitters cannot be present in every country and therefore usually operate through a network
of remitters spread across the world. This model is a prudent and efficient one, as setting up a
presence across the world could be a challenge from a financial, regulatory and operational
perspective. Large remitters may be exceptions to this model and do operate on their own
across the world. In every location, remitters may further outsource their activities to agents.
Agents can be small mom-and-pop stores, large banks or retail chains. Agents act on behalf of
the remitter.
The remittance industry is relatively unorganized but highly regulated. Regulatory requirements
vary by country but all ask for very strict KYC (Know Your Customer), AML (Anti Money
Laundering) and CTF (Counter Terrorist Financing) checks on customers and define volume
and value limits on transactions. Therefore, all remitters must have systems in place to ensure

of 23
all regulatory requirements are complied with for every transaction. Failure to comply can result
in huge fines and in some cases even cancellation of the license to operate.
To ensure regulatory compliance, remitters own and maintain their central transaction
processing engine and data store. Transactions from the send agents are routed though the
central processing engine where they undergo all required compliance checks before they can
be sent forward to the payout remitters for payout processing. The central engine also manages
all reconciliation and settlement processes between the send and payout sides of the business.
1.3 INTEGRATION CHALLENGES
As mentioned above, remitters use their own systems to capture, validate and process
transactions. The network business model requires transactions to be routed from the sending
remitter’s system where they are initiated, to the payout remitter’s system where they will be
disbursed. There needs to be constant communication and feedback between the two
disconnected systems to keep them synchronized about the status of the transaction.
Failure to achieve a near-real time synchronization can lead to financial losses. For example, if
a sending customer chooses to cancel a transaction, the send remitter must be sure that the
transaction has not yet been paid out before a cancellation can be initiated. If a paid out
transaction is cancelled, the businesses will lose the transaction amount as it would be
simultaneously paid out to the beneficiary and refunded to the sender.
In addition to transactions, other information also needs to be exchanged between send and
payout remitters. Remittances generally involve transactions across countries and currencies.
Foreign exchange rates offered by payout remitters may be updated on a daily or more frequent
basis and need to be updated in the sending remitters’ systems. Rules, such as transaction
limits or mandatory information requirements, may be updated as regulations change and need
to be synchronized across remitter systems.
This back and forth exchange of transactions, acknowledgements, status updates and
information requires complex integrations between systems. Further, a remitter works with
multiple other remitters, creating a many-to-many relationship and therefore a many-to-many
systems integration requirement.
While a network of remitters is a practical business model, it is exactly this model that poses
technical challenges in the design and implementation of systems integration, communication,
synchronization, data integrity and security and standardization.
This paper outlines the current approach used for systems integration and its limitations and
proposes a new technical approach for systems integration that can help overcome these
limitations.
2 SYSTEMS INTEGRATION
2.1 CURRENT APPROACH
To facilitate the integration of remitter systems, a common solution is for remitters to publish
their independent APIs (Application Programming Interface). Remitters connect to the API of
partner remitters to either push or pull transactions and other information to or from the partner

of 23
remitters. If one remitter publishes an API, the partner remitter must develop the API client.
Both remitters may have an API, in which case any one of them develops the client. So it is
common overhead that a remitter not only has to maintain its own API but also develop client
applications to connect to partner APIs.
Some remitters, who don’t have the technical wherewithal, may work with a simpler but less
efficient and error-prone mechanism of file transfers.
Figure 1: A representation of the many-to-many system integrations
2.2 LIMITATIONS OF THE CURRENT APPROACH
The most significant limitation is that neither the APIs nor the data formats follow any design
standards. Every integration therefore has a steep learning curve for the developers at every
remitter to understand the partner’s process flow and data structures. Due to the absence of
standardization, the initial integration between partner remitter systems requires a lot of effort
and time and a lot of testing.
If there is a change to the API for any one remitter, all partner remitters who use that API must
make changes to their API client. Thus, the integration needs to be continuously maintained and
upgraded to support frequent changes to business models and regulatory requirements.

of 23
This results in a significant IT development and maintenance cost. In addition, delays in
integration lead to a loss of competitive advantage and a direct loss of revenue. In the case of
changes due to regulatory requirements, delays can have even more severe implications.
3 THE UNIVERSAL API SOLUTION
3.1 PROPOSED APPROACH
A notable characteristic of this inter-system data exchange is that it can be asynchronous. Thus,
a send transaction can be created by the send remitter and the customer interaction completed
without needing to connect to the payout remitter system. Similarly, a payout remitter can
complete a transaction with a customer without needing to connect to the send remitter system.
The data exchange and synchronization should preferably be as close to real-time as possible
so that data across systems is reasonably accurate at any given point in time.
The crux of the solution proposed in this paper involves changing from a many-to-many
integration model to a many-to-one integration model. For a simple conceptualization, we can
consider that the solution proposes to replace a point-to-point model with a hub-and-spoke
model.
Figure 2: Point-to-point (left) and hub-and-spoke (right).
Instead of every remitter integrating with the system of every other remitter, each remitter will
only need to integrate with a centralized platform with standard API interfaces and data
exchange formats. The API will be based on REST specifications which can be invoked by a
client written in any technology. The access protocols will remain the same, making it easy to
program multiple clients, including web and mobile. Remitters will not be required to develop or
maintain their own API.
The centralized platform will act as a store-and-forward system to move transactions,
acknowledgements and other data between remitters. Remitters will continue to maintain their
own private data stores and processing engine, keeping their customer and transaction
information confidential.
Remitters will continue to maintain and run their own compliance rules to ensure they only send
or receive transactions that are compliant with their company’s or their country’s regulations.

of 23
Figure 3: A representation of the many-to-one system integrations

of 23
3.2 DATA EXCHANGE SEQUENCES
A data exchange comprises of a request and a response. The originator of the transaction, the
send remitter, sends a request to the payout remitter. The response from the payout remitter
can be an acknowledgement, a confirmation of action or a rejection of the request.
Remitters must follow a data exchange protocol to ensure messages are correctly processed in
asynchronous mode. Requests must be processed in order of time in which they were posted.
Each message can be one of the following types:
Message Type Description
REQ_NEW
This is new transaction. Posted by a sending remitter for processing by a
receiving remitter.
REQ_MOD
This is a modified transaction following a REQ_NEW transaction, if there
are any modifications to the original transaction. Multiple REQ_MOD
transactions may be sent, the latest one will be considered.
Posted by a sending remitter for processing by a receiving remitter.
REQ_CAN
This is a transaction cancellation request following a REQ_NEW or a
REQ_MOD transaction, if the transaction needs to be cancelled. Only one
REQ_CAN transaction may be sent per transaction.
Posted by a sending remitter for processing by a receiving remitter.
REQ_ACK
This is a request acknowledgement to confirm receipt of any one of a
REQ_NEW, REQ_MOD or a REQ_CAN transaction. A request
acknowledgement does not mean that the transaction has been
processed, it only means that the transactions has been received for
processing.
Posted by a receiving remitter to a sending remitter.
CNF_PAY
This is a confirmation of payment indicating that the transaction has been
processed and successfully paid out. This follows a REQ_ACK. This can
be sent in response to a REQ_NEW or a REQ_MOD transaction. There is
no confirmation just for the modification, if processed successfully the
response is a CNF_PAY.
CNF_CAN
This is a confirmation of cancellation to confirm that the transaction has
been successfully cancelled. This will be sent in response to a REQ_CAN.
CNF_ACK
This is an acknowledgment of a confirmation to confirm receipt of any one
of CNF_PAY or CNF_CAN.

of 23
The data exchange sequences for new transactions, transaction cancellation and transaction
modification are illustrated below. For information updates such as FX rates, rules and remitter
information, the sequence will be a request and an acknowledgement.
Posted by a sending remitter to a receiving remitter.
REJ_NEW
This is a rejection of a new transaction request to indicate that the
receiving remitter received the transaction but was not able to process it
successfully. This follows a REQ_ACK.
REJ_MOD
This is a rejection of a transaction modification request to indicate that the
receiving remitter received the modification request but was not able to
process it successfully. Note that this is a rejection of the modification
request, the original transaction may still be processed successfully.
REJ_CAN
This is a rejection of a transaction cancellation request to indicate that the
receiving remitter received the cancellation request but was not able to
process it successfully. Note that this is a rejection of the cancellation
request, the original transaction may still be processed successfully.
REJ_ACK
This is an acknowledgement of a rejection to confirm receipt of any one of
REJ_NEW, REJ_MOD or REJ_CAN.
Posted by a sending remitter to a receiving remitter.

of 23
Figure: New Transaction Data Exchange Sequence
A new transaction request message is posted by the sending remitter to a payout
remitter. The payout remitter retrieves the message and acknowledges it with a
response message. An acknowledgement only means that the message has been
received but not processed.
The first part of the data exchange is completed with no status changes to the
transaction except an indication that the sending remitter need not post that
transaction request again.
The payout remitter may process the transaction, in which case it will return a
payment confirmation message along with the beneficiary details to the sending
remitter. The sending remitter will acknowledge that the payout confirmation has been
received and the transaction lifecycle is complete with an end status of paid.
If the payout remitter is not able to process the transaction for any reason, it will return
a request rejected message to the sending remitter along with a reason for rejection.
The sending remitter will acknowledge the reject message and determine whether to
cancel the transaction or send a new transaction request after correcting the problem.

of 23
Figure: Transaction Modification Data Exchange Sequence
A sending remitter may send a modification request for a transaction already sent
earlier. The payout remitter will check if the original transaction has been paid out or is
still awaiting processing. If it has been paid out the modification request will be
rejected. If not, the original transaction request will be rejected and the modification
request will be taken up for processing.
A payment confirmation will be provided for the modification request.

of 23
Figure: Transaction Cancellation Data Exchange Sequence
The cancellation request process is similar to the modification request process. If the
original transaction has not been paid out the cancellation is acknowledged and
confirmed cancelled. Or else, the cancellation request is rejected. Unlike a payment
confirmation which usually happens a while after receiving a request, a cancellation
confirmation may follow immediately after an acknowledgement of a cancellation
request.
A cancellation request may be sent on a new transaction request or on a modification
request. It will apply to the current transaction under consideration. For example, if a
modification request is accepted, any subsequent cancellation will apply on that
request. If a modification request is rejected, any subsequent cancellation request will
apply to the original new transaction request.
To guarantee consistency, requests must be processed in the order they were posted.
A modification or a cancellation request should be posted only after the original
request has been acknowledged.

of 23
3.3 REST INTERFACES
The API is a REST implementation and supports the HTTP protocols: POST, GET, PUT and
DELETE. The API implements methods for each of the resources listed below. Together they
offer all the functionality required to complete a remittance transaction between send and
payout remitters.
Figure 3: Resources supported by the universal API
See Appendix A for a list of interface methods.

of 23
3.4 DATA EXCHANGE MESSAGE STRUCTURES
All data exchange messages will use a standardized structure, using the lightweight and open
JSON format. Data structures will be predefined based on industry best practices. The use of
JSON and a NoSQL data store, will permit modifications to the data structure as required by the
partner, as long as the mandatory fields and primary keys are kept intact.
A message sent from one remitter to another via the universal API has two parts: the metadata
and the data.
The metadata contains information that is required by the universal API to route the data to the
intended remitter and tracking information such as the message id, date and message type. The
metadata is unencrypted and can be read by the universal API.
The data can contain new transaction information or response information or update information
for FX rates, remitter details or rules. Data is encrypted using PKI encryption and can only be
decrypted and read by the intended recipient.
The metadata comprises of:
 a universally unique id which identifies the
message
 the remitter id (issued by the Universal API) of
the sending remitter and of the recipient
remitter which helps the API route the
transaction correctly
 The message type
 The date and time the message was posted
Figure: Metadata structure
See Appendix B for a list of data structures.
3.5 INTEGRITY, CONFIDENTIALITY AND NON-REPUDIATION
The single most important characteristic of this platform, given the highly regulated nature of the
industry it services, is that it can only act as a facilitator for data exchange and cannot have any
visibility into the data being exchanged or have any decision making capability, except to the
extent of routing data between the specified partner remitters.

of 23
Figure 4: Encrypted data transfer using PKI
The platform uses PKI (Public Key Infrastructure) to enforce security. Every remitter on the
platform will be issued an individually unique digital certificate (public key-private key pair).
Remitters will share their public keys with their partner remitters only. Send remitters will encrypt
transaction data using the public key of the payout remitter for which the transaction is intended.
This will ensure that only the intended payout remitter can decrypt and process the transaction.
Similarly, a payout remitter will encrypt response data using the public key of the send remitter
for which the response is intended, thus ensuring that only the intended send remitter can
process the response. The use of digital certificates will also provide a non-repudiation
mechanism, whereby it will be possible to confirm without doubt that the transaction was indeed
sent or paid out by the specified remitter.
4 TECHNOLOGY STACK
The two key components of the solution are the REST API and the store-and-forward data
store. The choice of a NoSQL database for the data store was driven primarily by the need for a
flexible data structure, which would have been very difficult, if not impossible, with an RDBMS.
Further, given that the data to be stored is immutable and there are no updates or writes, the
NoSQL paradigm was perfectly suited.
JSON, being a lightweight format, easy for humans to read and write and easy for machines to
parse and generate, was clearly the format of choice for data exchange. This could however
mean a significant transition for legacy systems that use XML, which was the format of choice
before JSON.
While there are several server-side environments which are equally good, Node.js has some
advantages with its ability to create highly scalable servers without using threading, by using a
simplified model of event-driven programming. For this reason, and further reinforced by the
possibility of having a unified JavaScript development stack, the choice for API development
was clearly Node.js.
In addition the availability of a large number of high quality libraries and frameworks makes
development of critical modules in Node.js easier and more robust. The main framework for API
used in this development is Express, a routing and middleware web framework. The routing and
authentication middleware make it very easy to secure REST API endpoints with access control.

of 23
Mongoose, an object modeling solution for Node.js, is used to access the MongoDB NoSQL
database. Mongoose provides a straight-forward, schema-based solution to model application
data. It includes built-in type casting, validation, query building and business logic hooks.
Finally, the API interface is made available to developers using the Swagger specification, a
powerful definition format to describe RESTful APIs. The Swagger specification creates a
RESTful interface for easily developing and consuming an API by effectively mapping all the
resources and operations associated with it. It’s easy-to-learn, language agnostic, and both
human and machine readable.
The entire solution may be hosted on the cloud using, for example, Amazon Web Services
compute and storage instances and the MongoDB Atlas hosted service. For the API, one of the
several API management solutions, such as the Amazon API Gateway, may be used.
Figure: A graphical representation of the technology stack. All logos are used for
representational purposes only and do not imply any affiliation with or endorsement by
the companies that own the logos. The prototype is developed using the open source
or community editions of all software listed.

of 23
5 CHALLENGES
There are two major challenges from a business perspective that could hold up adoption of the
universal API and standardized data exchange formats.
If all the partners of a remitter are not on the platform, there will continue to be an overhead of
maintaining some additional API connections over and above the universal API.
Several remitters have custom data exchange requirements, either due to legacy data
structures or due to internal regulations. Although the NoSQL schemas are flexible and can
accept variations in data structures, there will be some planning required to ensure the data
structures exchanged are as expected from both sides.
From a technical perspective, the biggest challenge will be the change from XML to JSON for
remitters whose systems currently use XML.
6 CONCLUSION
The Universal API is a solution that demonstrates clear and tangible benefits in the form of
improved transaction processing efficiency and reduced costs of IT development, support and
maintenance for remittance service providers.
The Universal API however, has no role to play in the capture, validation or processing of
transactions. It is only a routing engine for transaction requests and responses and other data
exchanges between partner remitters.
The biggest hurdle for a global implementation will be to get consensus and agreement on the
API interfaces, the data exchange sequence and the data exchange formats from all
participating remitters. And as an extension, getting a critical mass of remitters to participate to
truly establish the data exchange standards as an industry norm.
A working prototype to demonstrate the interfaces provided by the Universal API and the data
exchange formats is available at http://api.remitbroker.com/v1/interface. Along with an
implementation of the API and documentation, the prototype includes a web application that
allows remitters to simulate and test the data exchange sequence for transaction requests and
responses and for data updates and acknowledgements.
The next step towards making this solution a reality will be to float an RFC (Request for
Comments) in remittance industry forums, collate, review and discuss feedback and incorporate
relevant and useful changes into the API and data exchange standards. Once there is
agreement amongst the majority of remittance service providers, the platform can be rolled out
for use in production.

of 23
7 GLOSSARY
Remittance Remittance is a service to individuals to allow them to send money
from one location to another, usually across countries. Generally,
at least one side of this transaction is in cash, since for non-cash
transfers regular banking channels are more commonly used. The
other side can be cash, a bank account or a mobile wallet.
Remittance Service
Provider
a.k.a. Remitter
A business that offers remittance services and maintains IT and
operations infrastructure to capture, validate, process and pay out
remittance transactions.
The term used in this document is Remitter.
Agent Remitters often work with a network of businesses who conduct
transactions on behalf of the remitter. These are known as Agents.
Agents can be a bank, retailer, gas station, grocery store or any
other business that offers these services alongside its primary
business.
Send All remittance transactions are two-sided, two-party transactions.
The process of initiating the transaction is referred to as the Send
side of the transaction. Accordingly, remitters that initiate
transactions are referred to as Send Remitters or Send Agents and
customers are referred to as Send Customers or Senders.
Payout The corresponding process of paying out the transaction is referred
to as the Payout side. Accordingly, remitters who payout
transactions are referred to as Payout Remitters or Payout Agents
and customers are referred to as Payout Customers or
Beneficiaries. A remitter may both send and payout transactions, in
which case its role will change from a Send Remitter to a Payout
Remitter depending on the transaction.
Partners Send Remitters and Payout Remitters work in pairs to complete a
transaction and are referred to as Partners of each other. Every
remitter may have multiple partners.
Transaction A Transaction starts when a send customer initiates the process to
send money and is completed when the beneficiary receives the
money. A transaction goes through a business workflow and is
assigned a status at each stage of the workflow, until it reaches an
end-state.
FX Rates Since a large part of the money transfer business involves sending
money across countries and currencies, the conversion rate from
one currency to another is referred to as the Foreign Exchange
Rate or FX Rate, a standard industry term.

of 23
8 APPENDIX A: API INTERFACES
For details on the API interfaces and data structures please see the universal API interface at
http://api.remitbroker.com/v1/interface

of 23
9 APPENDIX B: MESSAGES AND DATA STRUCTURES
For details on the API interfaces and data structures please see the universal API interface at
http://api.remitbroker.com/v1/interface
9.1 TRANSACTION REQUEST

of 23
9.2 FX RATE UPDATE

of 23
9.3 RULE DATA 9.4 RESPONSE MESSAGE

Universal api dataexchangestandards_remittanceindustry

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Universal api dataexchangestandards_remittanceindustry

Similaire à Universal api dataexchangestandards_remittanceindustry (20)

Dernier

Dernier (20)

Universal api dataexchangestandards_remittanceindustry