PIB Technology delivered the design and development of a digital-asset cash-in and cash-out program for a private bank. The bank needed to know who owned an exchange account, what funded it and whether the investment activity explained a withdrawal. The aim was to make digital assets an explainable part of a client's financial picture, alongside securities and cash, before any money moved.
The program linked verified fiat funding, exchange activity and wallet-risk evidence to a controlled banking workflow. An eligible request became an encrypted payment instruction, bank processing and an account advice returned to the application. PIB Technology worked with the bank's compliance and operations teams, the application and wallet-analysis developers, a bank-interface supplier and exchange counterparties. Each record, from an exchange trade to a bank advice, kept its own owner.
01 / The problem
The financial explanation had to survive the handoffs
A bank statement shows that money moved, and an exchange balance shows what remains. Neither explains where the funds came from or whether trading supports a withdrawal. The starting question was whether a bank could accept digital-asset-related funds with an adequate explanation of their origin and value. The program's answer joined identity and same-name funding with transaction history and a reviewable cash-out request. Identity checks did not prove the economic origin of a balance; transaction history did not prove account ownership.
For an investment relationship, this history belongs alongside securities holdings and cash. The program specified the digital-asset activity needed for that wider view. Connecting it to the securities ledger and combining returns across asset classes were separate design problems, taken up in section 04.
02 / Inside the system
Three evidence domains, one banking boundary
The design has a customer-and-funding domain, an investment-activity domain and a bank-processing domain. Onboarding captured identity, profile and supporting documents. The design fed exchange transactions and balances to a tracker, and wallet-audit and transaction-risk checks to source-of-wealth review. Only eligible cash-out requests progressed to the bank interface.
The bank-side specification introduced a wallet identifier as an address attribute, customer segment classifications for retail and exchange relationships, and a structured permitted-beneficiary field on the money account. Core records included the person, business partner, account container, money account and e-banking contract. An onboarding identifier and UTC timestamp linked application files and replies; a transaction identifier linked payment instructions. These data contracts belong to the bank-side specification; the tracker's database schema is outside it.
The first scope sent the minimum banking data to the core. Fuller profiles stayed in onboarding and documents in temporary bank storage. That staging reduced initial integration scope while leaving document continuity and profile migration as separate responsibilities.
- Customer and funding records
- Identity/profile, wallet reference, onboarding identifier and permitted-beneficiary data.
- Investment evidence
- Specified transaction and activity fields, tracker and wallet audit; the return calculation method was a separate specification.
- Bank interface
- GPG-encrypted onboarding/APF XML, SFTP, bank processing and CAMT.054 advices with application callback.
- Operating controls
- Compliance escalation, core-availability stop, payment repair, error monitoring and periodic reconciliation.
03 / Inside the system
The cash-out workflow had a request path and a return path
An exchange sell request entered the onboarding application through the exchange interface. The November 2018 specification placed transaction-risk and AML validation before generation of an APF payment XML file. The application encrypted the file and sent it over SFTP to the bank’s processing environment. The exchange-facing implementation sat outside the bank-side supplier's scope.
Bank processing produced a CAMT.054 account-movement advice. The application decrypted and processed that advice, then notified the exchange through a callback. An instruction arriving at the bank was therefore different from a completed payment and from the exchange reconciling its own bookings. The specified exception path sent an unprocessable payment to manual repair.
External cash-out was another step: the customer used e-banking to pay the configured funding-bank beneficiary. Online validation required the core to be available; if it was unavailable, the order stopped. The payment then followed regular bank AML checks and payment circuits. The workflow combines application logic, banking controls and human review.
A worked example
A sell request reaches the payment-review boundary
Example with invented data.
01 / ContextIdentify the customer and original funding
The request references the customer relationship, exchange account and original funding trail. Same-name funding helps link the accounts, while supporting documents explain the source of funds.
02 / ExplanationCompare activity with the proposed withdrawal
The tracker brings transactions and balances into the financial explanation. Wallet and transaction-risk checks add evidence. An unexplained transfer or unsupported gain remains a review issue; a favorable chain signal cannot fill the missing explanation.
03 / InstructionGenerate a payment instruction only after the specified validations
For an eligible exchange-to-client cash-out request, the application produces and encrypts APF payment XML for SFTP delivery. The supplier design specifies this handoff. The return algorithm and the exchange adapter are separate components.
04 / Bank processingProcess the instruction—or repair the exception
Bank processing executes the fiat instruction or sends the payment to manual repair. Operations own the exception. An encrypted file's arrival is not a completed payment.
05 / FeedbackReturn advice and reconcile the exchange booking
CAMT.054 advice returns through the application, followed by the exchange callback. The exchange compares that advice with its own bookings. A later external-bank withdrawal uses the configured beneficiary and regular bank checks.
04 / Inside the system
Activity fields were explicit; return accounting remained a separate specification
The July 2018 design material called for timestamp, asset, buy/sell activity, amount, gains/losses and account/activity statements. These fields explain the reporting intent. They do not by themselves define a calculation that can reconcile a withdrawal with funded capital and investment performance.
A defensible combined view of digital assets, securities and cash also needs reference prices and dates, currency conversion, fees, cost-basis and lot policy, and treatment of transfers or other asset events. Those mechanics need an agreed method. The design included valuation and return outputs as an analytical layer, separate from the bank's fiat ledger and from chain-risk evidence.
A wallet identifier is a reference to an address, rather than proof of beneficial ownership. Blockchain movement can support provenance analysis, while identity documents, exchange records and a funding trail supply other parts of the explanation. The responsible reviewer still has to assess gaps and inconsistencies.
05 / Inside the system
Scope choices made the first delivery possible—and left work to finish
The design traded a broader first release for a bounded interface, restricted transfer destinations and explicit operational intervention. Each choice carried a cost that mattered at acceptance.
- Decision 01
Verified funding and a permitted destination
Associate eligibility with same-name bank funding and attributable gains; store a configured external beneficiary.
The model sought a traceable connection between original funds, exchange activity and the requested withdrawal.
Trade-off. The model restricted available funding and destinations, and still depended on adequate activity evidence and bank review. It did not remove illicit-funds risk by itself.
- Decision 02
Encrypted files for the first bank interface
Stage the initial bank interface through encrypted XML on SFTP.
The specification prioritized a constrained first delivery within the program's time window.
Trade-off. Transport, encryption, import and asynchronous replies required separate handling.
- Decision 03
Minimum core data before fuller migration
Create operational bank objects from mandatory data while retaining fuller profiles and documents outside the core initially.
The first scope needed functioning accounts before the complete target data/archive structures were available.
Trade-off. Document lookup and profile continuity became separate acceptance work.
- Decision 04
Manual repair and reconciliation
Use error replies, bank repair workflows and periodic reconciliation lists alongside automated file handling.
The specified design kept existing bank operations at incomplete integration boundaries.
Trade-off. Human workload, exception ownership and timely closure became part of the operating model.
06 / Inside the system
Qualify the interface, the explanation and the operating decision separately
The supplier’s tests covered valid and malformed onboarding/payment XML, encryption and import, reply generation, domain values, country/currency variations and generated-record maintenance. UAT used actual application-generated files.
The internal interface test ended at file processing and returned messages; sending through the external payment network was outside its scope. Exchange integration, return calculations, bank risk acceptance and external payment completion sat outside that test.
Operational control included periodic comparison of onboarding identifiers, dates and statuses, monitoring of discarded client-data orders, error replies on the application side and exchange reconciliation of account advices against its internal books. Corrections were manual.
- Did the bank interface handle the file correctly?
- The supplier tested positive and negative XML, encryption, import and replies.
- Does activity support the calculated return?
- Only with an agreed valuation and cost-basis method, reference inputs and expected-output reconciliations.
- May this customer make this payment?
- Identity, source of funds, beneficiary restrictions and bank risk authority remain distinct from chain analytics and transport correctness.
- What sits beyond the interface test?
- Exchange callbacks, external payment completion, operating controls and release acceptance each need their own verification. The supplier's interface test excluded external payment-network execution.
07 / Inside the system
Delivery crossed distinct teams and decision rights
The bank program combined Board sponsorship, compliance and central-file operations, application developers, a bank-interface supplier and prospective exchange counterparties. Supplier scope, application scope and bank operating acceptance were separate handoffs.
The program developed the control model and detailed interfaces while readiness forecasts and pending approvals changed. PIB Technology connected the use case to verified funding, activity reporting and controlled withdrawals; supplier specialists authored the detailed bank interface design.
The people around the workflow.
- Board and program sponsor
- Product intent, supplier/counterparty evaluation and governance.
- Bank compliance
- Customer-risk escalation, AML interpretation and operating acceptance within bank authority.
- Bank operations and central file
- Generated records, supporting documents, manual repair and periodic reconciliation.
- Application and wallet-analysis teams
- Onboarding, tracker and wallet-audit functions and the application side of interfaces.
- Bank-interface supplier
- Specified core objects, payment-file processing, account advices and scoped interface tests.
- Exchange counterparties
- Their activity records, request/callback interface and reconciliation to internal bookings.
The design principle
Preserve the financial history, distinguish evidence from permission, and make the payment decision accountable.