Banco Arbi - A receivables assignment platform
Three web modules for assignor, assignee and back office to trade receivables, with the APIs published on the bank's corporate gateway.
Turning future payments into liquidity
A company that has issued bank slips has money coming in later and, sometimes, needs it now. Assigning those receivables to a third party is a well known operation, and what is usually missing is the digital path to carry it out.
Banco Arbi wanted to give that path to its account holders. The platform built lets them select slips issued by the bank, choose who to assign them to, set the split rule and submit the operation, without leaving the browser.
Three audiences, three modules
The design started from a simple observation: the party assigning, the party receiving and the party approving have different needs and cannot share the same screen.
- Assignor. The account holder who owns the receivables. Overview dashboard, assignee registration and management, the assignment itself, and reports. Assignee. Whoever acquires the receivable. Listing of what is due, settlements and event history, entering through an emailed invitation and completing their own registration. Bank back office. Where the operation is validated. Dashboard, assignee registration validation, settlement queue and reports.
The assignment, in five steps
The heart of the platform is the assignment flow, designed as a step by step rather than a single form:
- Choose the receivable. Slips due or already overdue, issued by the bank. 2. Choose the assignee. One or more, among those previously registered and validated. 3. Choose the modality of the operation. 4. Set the split. By percentage or by amount, when there is more than one assignee. 5. Set the cost of the operation.
At the end, the order goes to the back office, which validates or rejects it with a reason and sends it to the settlement queue.
Breaking the operation into steps is not interface decoration. In a financial flow with more than one party, each step is a checkpoint, and it is cheaper to catch a mistake at step two than to find it after the order has been submitted.
When the corporate platform is the limit
This project has a technical story worth telling, because it contradicts the expectation that the hard part is writing the code.
The APIs were published on the corporate gateway the bank already used, and three limits appeared along the way:
Name collision when joining data. When combining tables, the gateway merged attributes with the same name and overwrote values, returning wrong data when reading an assignment.
Missing identifier for the created record. The platform did not return the identifier of what had just been written, which forced temporary workarounds to keep development moving.
Interceptor limitation. Trying to solve bulk insertion through the gateway itself ran into unexpected behaviour in item counting, blocking the loading of receivables and assignees.
Tickets were opened with the vendor, and the definitive fix for reading did not come from the platform. It came from a modelling change proposed by the bank's own team: writing the structure already in the shape it would be consumed in, avoiding the problematic join.
It is a good portrait of mature corporate integration. When the obstacle is the tool, the way out is usually a joint modelling decision, not insisting on a path the tool does not support.
Stack and practices
- Angular across the three web modules, with a responsive interface, including replacing tables with adapted cells on small screens. APIs published on the bank's corporate gateway, with routes separated by profile and token authentication. Client managed relational database, with data modelling, object creation, scripts and procedures delivered by X-Apps. Low and high fidelity prototypes of all three modules, delivered with preview links before development. Functional design document for the solution, written before construction. Assignee invitation and registration flow documented as a process, not only as a screen. Sprints with a board per sprint and daily follow-up, in a channel agreed with the client.
One detail about the way of working: the communication channel with the bank was defined in the contract, with sprints and impediments recorded in the same place the team talked.
Need to build on the platform your bank already runs?
In financial environments, the corporate gateway, the database and the access rules already exist, and the new solution has to fit inside them. X-Apps builds within those constraints, documents what the platform does not deliver and proposes the alternative path instead of pushing the problem forward.