Make Good Use of Your Sidebar

More content coming soon...

Blog Index
The journal that this archive was targeting has been deleted. Please update your configuration.

Why Banking is Divorcing Itself from Banks

Banks have always been at the heart of payments and banking services. Whether you were collecting, storing or sending funds there was always a bank facilitating the movement of money. However, as technology has evolved and the demands of the consumer have changed, banks are losing the firm hold they’ve held on banking services for 3 main reasons. 

1) People Are Losing Confidence in Banks

A recent Gallop poll shows that Americans’ confidence in banks has fallen to 21% - a record low. The government bailouts and the increase in fees that banks are charging are the main reasons for this concern. Banks are no longer neighborhood institutions with strong community ties. This lack of trust is creating a strong demand for alternatives to banks. Sites, like, are helping people leave their banks to find easier, trustworthy solutions that meet their needs.

2) More Flexible Banking Services With Social Networks

Traditionally, the role of the bank was to authenticate the identity of individuals and associate them with deposits and transactions. The process that banks use is outdated and hasn’t advanced with the technology of today. PayPal, over a decade ago, became the DNS for banks by associating an email address with a bank account. This simple idea has transformed online payments, yet most banks have failed to adapt or offer similar services.

Similar to PayPal, online networks now have a tremendous opportunity to associate Twitter and Facebook accounts with bank accounts. The flexibility that email and social networks bring provides limitless possibilities for banks. Conducting transactions via social networks or using your Twitter handle to submit payment at an online store is something we’re not too far from. APIs published by social networks make this an easy transition. A couple months ago we created a Twitter payment platform called TweedlePay in just 3 days on BancBox based on the existing Twitter APIs.

Social networks have the ability to subsume most online activities, including banking and payments. When it comes right down to it, there really is no advantage that banks hold over the social Web.

3) Better User Experience Outside of Banks

In addition to flexibility and trust issues, banks offer a poor user experience. Granted, most banks offer simple online and mobile banking services, but there is still a lot to be desired. has set the standard for what a good banking experience should be. While you can’t perform transactional services with Mint, it brings more clarity to peoples’ banking and helps them set and meet financial goals.

Such experiences don’t exist with banks. They’ve tried to make banking a standalone product, but have failed to make one that offers the services, features or UX that other tools on the market provide.

This is a critical time for banks. While they are needed for regulatory control of finances, consumers are beginning to switch their allegiance to anyone who can provide them a better experience. Its up to banks to re-establish a connection with their customers and provide a better user experience or they will be relegated to purely the back-end role of banking.


Use Case Example - Rent Payments

A popular use case for the BancBox APIs are products that streamline the way landlords receive payments from renters, including non-recurring payments for rental properties, normal recurring payments from renter to landlord, and cases involving split payments from multiple roommates to a landlord. These use cases are easy to address using the BancBox APIs.

In this post, we will demonstrate a simple example of how you can create a payments flow for landlords using the BancBox APIs

First, lets consider some of the high-level functionality that needs to be achieved:

  • Create accounts for landlords for the settlement and disbursement of rent payments
  • Create a tokenized wallet for renters to store their payment information
  • Allow automated payments by ACH from renters
  • Allow landlord to select how they want to get paid, and set up an automated disbursement method for that payment method
  • Collect fees for the marketplace owner
  • Monitor incoming payments for errors

BancBox offers flexibility to craft a funds flow that best suites your product's needs. Consider the funds flow below:  

 First, a landlord registers into the subscriber's rental payments portal, and creates an account (see step 1 above). The landlord is essentially creating a payments holding account that the subscriber is able to manage. Three API methods can be used to complete the landlord setup. 

  1. CreateClient - Use the createClient method to initiate the setup for the landlord. Since the landlord will be receiving payments from the system, it is prudent to make sure the landlord is properly identified. BancBox does identity verification automatically by passing in the landlord's name, DOB, and SSN. A client id will be generated for the landlord.
  2. OpenAccount - Once the client is created, the subscriber simply opens a bancbox account using the client id generated in the create client step. An account id will be generated for use in inbound payments and outbbound disbursements later.
  3. LinkPayee - With the landlord client registration complete, it is also useful to assocate the landlord's bank account for automated disbursements. This will generate a linked payee id for disbursing funds later.

Now that the landlord is created, we will assume there is a registration flow that allows the renter to initiate a payment to the landlord. It is useful in this step to also use createClient so a virtual wallet can be created for the renter (see step 2 above), and payment source details stored in that wallet. We will use two methods to setup the renter, createClient and linkExternalAccount:

  1. CreateClient - Create a client (user) entity in the BancBox platform. This will allow payment details to be stored for the client so payments can be automated later. A client id will be generated from the API request.
  2. LinkExternalAccount - Create a "wallet" for the renter so payment details can be stored.

 Once the renter client is created and a bank account associated to that client, payments can be scheduled using BancBox's CollectFunds API method (see step 3 above). When using CollectFunds, the subscriber specifies the renter's client id, and linked external account as the source of the payment, the landlord's BancBox account as the desitnation of the payment, an amount, and a schedule date or dates.

When the renter payment clears, good funds will be available in the landlord's BancBox account. The subscriber can extract fees from that account (step 4 above), and send the remaining funds to the landlord's business bank account (step 5 above). This is completed by using the following API methods:

  1. CollectFees - This will move funds from the landlord client's BancBox account into the subscriber's Fee and Revenue account.
  2. SendFunds - Disbursement of rent payments to the landlord's bank account is initiated by using the SendFunds method. In SendFunds, the BancBox account number is specified as the source, and the external payee id (generated in step 1) is set as the destination.

Fees collected from the landlord by the subscriber are automatically swept out of the subscriber's Fee and Revenue account on a daily basis into their external operations account (see step 6 above).

Payment status can be monitored by polling the BancBox platform using the GetSchedules API method.  


Routable Accounts and Card Present Transactions

We are pleased to announce the general availability of the BancBox R1.8 Release. This is a minor release, which includes a couple enhancements along with a set of bug fixes. We are making these enhancements and improvements as a constant endeavor to innovate, and provide our subscribers with the best user experience possible.

The major features in the release are:

1. Routable Accounts (BETA)

BancBox accounts are now “routable” with an account number and routing number to uniquely identify them on the NACHA network. This means that clients can now deposit funds into their BancBox accounts directly through ACH transfers from their external accounts without having to go through the BancBox API. A classic use case is the direct deposit of payrolls, but there are many ways you can use the functionality of dynamic creation of routable accounts, such as one time disposable debits.
The functionality is simple, when you create a new account using the OpenAccount API, simply specify whether the account should be routable for credits or debits.
Routability is disabled by default.
Please contact to enable it.

2. Credit Card “Track Data” in Collect Funds


The Collect Funds API now accepts credit card swipe / track data so as to allow subscribers to be able to collect funds from their clients through a swipe device. The transactions using track data will not require any other credit card information to be passed to collect Funds. A real life use case is collection of funds through kiosks or at retail stores.
Please visit our API documentation at for details.
Although the changes to the BancBox API in this release may not affect your Client portal's integration to the BancBox system, we strongly recommend that you update your client stubs with the new WSDL. Please also note that our next release, R1.9, scheduled for early August, 2012, will be fully backwards compatible with the R1.8 release.

3. Other Improvements

Besides the major features described in the previous section, there are several bug fixes that are available with this release. Below is a list of the key issues that are fixed.
  1. The error messages in both SOAP and REST API responses have been improved. We will be further improving on these error messages with our next release.
  2. The Length validations have been fixed for several fields in the API including accountNumber, payeeAccountNumber, amount, name, holderName, address, referenceID, subscriberReferenceID, bancBoxId, title, payeeName, comment, routingNumber, PaypalID, DebitCard and GiftCard.
  3. REST request format for collectFees and transferFunds is now similar as the other APIs. The additional wrapper for “request:{}” has been removed.
  4. Trace id is now being returned in the getAccountActivity API response.
  5. payeeAccountNumber is now optional for the linkExternalAccount API.
  6. Zipcode and state fields are now optional in the updateClient and updateLinkedPayee APIs.
  7. Issue with closeAccount SOAP API is now resolved.
BancBox Team



BancBox FAQs

 We received some great questions today from people interested in our platform.  Here are some answers and hope this helps:


International Businesses
Currently we can only support US-based transactions.  However, we are actively working towards an international solution, beginning with Canada and the UK. We're happy to explore your application to see if we can support you.

Transaction Limits
Yes, we do have limits but we set limits that are appropriate to your business after we go through our underwriting process.


Yes, we do have an underwriting process.  Once you've had a chance to play around with our API's and determine if we're the right solution for you, you can use the Go Live button on the sandbox environment to trigger off the Underwriting and approval process. The approval process is dependent on the type of transactions that you would like to process -  e.g. Credit Card / ACH, etc. 


We do charge for SVA accounts and for book transfers (SVA to SVA). Please refer to our pricing page for more details.  
  • Special pricing available based on volume and other considerations.
  • Please note that if you think you need help with money transmitter compliance, we have a separate fee for this given the risk/compliance needs.
Mobile Platform Support
Yes, our API's support all kinds of https transactions whether web or mobile. You can leverage our API's through your mobile applications in exactly the same way as you would call them through the web.


Integration to Other platforms
Q. Does Bancbox have plans to integrate with other payment platforms like Gumroad and Dwolla?
  • As a philosophy, we want to support as many platforms as possible.  
  • With respect to Gumroad, we’d be happy to work with Gumroad or support applications built on top of Gumroad.  See TweedlePay below.
  • On Dwolla, we think highly of Dwolla and the innovation they are bringing to payments.  We actually think there are ways we can work with them but don’t have any integration at the present time.  One potential difference between BancBox and Dwolla is that BancBox is not a consumer facing application. 

    We work in the background and allow our mobile/app developers to build their own brand.


What is "Tweedle Pay"?  
We built an app called “Tweedle Pay” in less than a week for the Finovate 2012. This is a demo app that we built to show the power of the BancBox platform.  You can see it in action at:
Our goal was to show you how you can launch your own type of payment service leveraging the BancBox APIs.

BancBox Inquiries

Hey All-

We've had a bunch of great questions about how to work with BancBox.

We're collecting all of them and will post a response by noon (pst) today that should address most if not all of them.



Stay tuned for exciting new developments.
Want to get in touch? Email us at
About Us Privacy Policy ©2013 All Rights Reserved.