PIB Technology delivered OBA, an automated international account-opening workflow, to a private bank. Opening an account across borders requires identity, residence, ownership, source-of-wealth and expected-activity evidence that supports the bank's decision to take the client. The bank needed that evidence collected, checked and routed to the right reviewer, and the approved client created in its existing core banking platform. The first scope covered individual customers entering a digital-asset-related banking service.
OBA joined a customer-facing application to the bank's due-diligence process and existing account model. The design automated the eligible path, routed elevated risk to authorized reviewers and exchanged encrypted account requests and results across an organizational boundary. PIB Technology coordinated application developers, a banking-platform supplier, an integration adviser, external control advisers and the bank's operations, compliance, risk and finance functions.
01 / The problem
The invariant: a complete application must become a valid bank record
The front end had to collect the information required by due diligence and by the bank's account model. Nationality, residence, account-holder identity, ownership and expected financial activity influenced both risk review and the records being created. An application could pass a document check and still require additional source-of-wealth evidence, review of a screening hit or institutional approval.
International onboarding moved between the applicant, relationship staff, compliance, senior risk decision makers and bank operations, and the file had to stay consistent across those handoffs. The goal was a fully automated route for eligible applications, with the bank's exception decisions inside the same process.
The first banking interface covered individual account opening. Phase-two specifications added broader account authorities, flexible KYC questionnaires, duplicate handling and long-term archive integration.
02 / Inside the system
An application boundary, an institutional boundary and a banking boundary
The customer application collected evidence and orchestrated verification, screening, risk calculation and signing. Bank compliance and the relevant committees owned exceptional relationship decisions. The approved account-opening data then crossed into the hosted banking environment through a dedicated file interface.
The November 2018 design specified XML protected with GPG and transferred over SFTP. Bank-side transfer and import components, including Zena and a File Transfer Adapter, supported creation of customer, account and e-banking objects. Replies were encrypted before transfer back to onboarding. This request–result exchange gave both sides a concrete boundary to validate.
Document retention followed a separate path. The first design used temporary bank storage. The phase-two specification added a daily archive feed of PDF files with XML metadata, with operations handling archive errors. Account creation and document archival were therefore different states.
- Customer workflow
- Rules-based collection, screening, identity verification, risk calculation and electronic signing.
- Institutional decisions
- Analyst hit review, bank compliance, enhanced due diligence, AML committee and Board escalation.
- Banking interface
- XML, GPG, dedicated SFTP, transfer/import jobs and encrypted result messages.
- Bank records
- Customer, account and e-banking objects in the existing core platform.
- Retention
- Temporary bank storage; daily document-and-metadata archive feed in the phase-two specification.
03 / Inside the system
Workflow design: automate the eligible path, route the exceptions
The process first screened customer information for hits and adverse media. An analyst reviewed hits to distinguish false positives from concerns requiring compliance evaluation. Identity-document and selfie verification followed, before the completed financial and personal information informed a rules-based risk calculation.
Compliance evaluated confirmed screening concerns. High risk, or an escalated concern, triggered enhanced due diligence and AML committee review. Politically exposed persons required a Board decision. Accepted applicants continued to populated forms, electronic signing, pricing assignment and account creation. Rejected applicants received the corresponding notification.
A worked example
An elevated-risk application
Example with invented data.
01Submit the required evidence
An international individual supplies identity and address details, a document and financial context. The application gathers the fields required for screening and the bank's account model.
02Resolve a screening hit
A screening match goes to analyst review. If it is a false positive, the workflow continues; a confirmed concern is escalated to bank compliance.
03Verify identity and determine risk
The document and selfie are checked, and the completed profile informs the rules-based rating. The application is rated elevated risk and needs additional wealth evidence.
04Obtain the institutional decision
Compliance conducts enhanced due diligence and presents the case to the AML committee. A politically exposed person follows the Board route. Rejection ends the account-opening path; acceptance allows it to continue.
05Sign and transmit the account request
After required approvals and signing, the application prepares an encrypted XML request. SFTP and bank-side import processing carry it into customer, account and e-banking creation.
06Handle the result and retention separately
An encrypted account result returns to onboarding. A content or import failure needs repair at its responsible boundary. In the phase-two archive specification, document failures go to operations independently of the account result.
04 / Inside the system
Choose interfaces and controls that match the operating constraints
The application was required to remain portable outside the existing banking outsourcing arrangement. That preserved an independent customer journey while making the bank's data model and interface contract central to delivery. An encrypted file exchange was the integration route.
The phase-two specifications distinguished a blocking validation failure from a possible duplicate person. A suspected duplicate could generate a central-filing issue for investigation while opening a new record. The archive design also assigned repair to operations rather than returning every failure to the onboarding application. These choices made operational ownership a necessary part of the interface.
- Decision 01
Keep the application portable
Own the customer application independently of the existing banking outsourcing arrangement.
The original request required client ownership and the ability to continue operating if the core-service arrangement changed.
Trade-off. Independence required a maintained data contract and explicit responsibility across the application and bank-platform teams.
- Decision 02
Use an encrypted file exchange first
Transfer GPG-encrypted XML over SFTP, with encrypted results returned to onboarding.
The supplier design offered an initial integration path into the bank's existing platform.
Trade-off. Transfer jobs, imports, results and error handling needed coordinated operation.
- Decision 03
Preserve institutional exception authority
Route confirmed screening concerns and elevated risk through compliance, due diligence and the appropriate committee or Board.
Risk acceptance depended on the bank's governance as well as verification results.
Trade-off. Exceptions interrupt the automated path and require a complete evidence package for the authorized reviewer.
- Decision 04
Assign archival recovery to operations
In the phase-two archive specification, park invalid documents and alert operations without returning an archive failure to onboarding.
The daily archive import was a separate operational process.
Trade-off. Successful account creation did not mean successful retention; operations needed to investigate and correct archive errors.
05 / Inside the system
Evaluate the data, the interface and the permission to operate
The supplier test design covered the file chain from transfer and decryption through import, reply generation and return encryption. Negative cases included malformed XML, wrong formats and values outside their allowed domains. Country, residence and currency variations tested behavior that a single successful account opening could miss.
Integrated acceptance used real application-generated files and bank validation of the resulting records. Restricted account opening in the bank's production environment, with funding and payments disabled, then tested the complete journey. The defects and improvement needs it exposed fed back into modifications. Bank acceptance, an independent control assessment and the material-outsourcing review each had their own owner.
- Does a valid XML file make a valid customer?
- Interface validity is one check. Customer acceptance also depends on identity evidence, screening, risk review and the bank's authorized decision.
- Does account creation mean the documents are archived?
- No. The phase-two design treats archival as a separate import. Metadata or document failures are parked for operations, without an application failure reply.
- Does supplier completion make the system ready to operate?
- No. The bank accepts the process, an independent assessor reviews the controls and the regulator reviews outsourcing. Supplier completion covers only the supplier's components.
06 / Inside the system
Give each dependency an owner and a reviewable handoff
Application and banking suppliers owned different components. An integration adviser coordinated completion and the interfaces between them. Bank operations validated mapped records; compliance and risk owned customer escalation and control assessment; finance supported commercial and contract work. External advisers contributed due-diligence and assurance requirements, while the regulator reviewed the relevant outsourcing arrangements.
Steering work connected those functions around delivery readiness. Discussions addressed supplier delays, bank data checking, field combinations and test coverage. A working component, an accepted bank process and authorized routine operation have different decision owners.
The people around the workflow.
- Applicant and relationship team
- Supply identity, address, financial information and supporting documents.
- Application developers and verification services
- Implement collection, screening, identity checks, signing and the outbound banking contract.
- Bank-platform supplier and integration adviser
- Coordinate transfer, import, account objects, results and integrated testing.
- Bank operations, compliance, risk and finance
- Validate data, resolve exceptions, assess controls and support acceptance and contracts.
- Board, external control advisers and regulator
- Provide the required risk decisions, assurance work and outsourcing review.
Technology and integrations
Services in the workflow.
- JumioIdentity-verification service
Identity-document authenticity and ID-photo/selfie matching in the onboarding workflow.
Identity verification
- AvaloqExisting core-banking platform
Existing banking platform; account/e-banking object creation through an encrypted import-and-reply interface.
Core banking platform
- KrollScreening analyst service
Analyst validation of screening hits and deeper screening before institutional compliance review.
Screening analyst review
- Duff & PhelpsAdvisory service
Due-diligence and control-design advisory work on risk, KYC/AML and consent/storage processes.
Control-design advice
- ComplyAdvantageScreening service
Initial sanctions and adverse-media screening with hits routed for review.
Sanctions and adverse-media screening
- DocuSignElectronic-signature service
Electronic signing of populated forms and contracts after institutional clearance.
Electronic signing
The design principle
Automation can prepare and connect the evidence; risk acceptance remains with the institution. The controls travel with the customer journey.