PIB Technology delivered the separation of a private bank from a shared, hosted core-banking service. The bank needed its own contracts, licenses, access rights and operating accountability while its banking services kept running. A parallel data design addressed a second problem: customer identities sat in a local client system, while accounts, pricing and transactions sat in the hosted Avaloq core.
The work combined a signed legal and technical separation scope, e-banking under bank-controlled access and the migration of real persons, addresses and authorities into the core. PIB Technology worked with a delivery adviser, platform and application suppliers, the bank's central-register and operations staff, and its risk and compliance functions. The two changes met at access control, customer-object mapping and bank validation.
01 / The problem
The invariant: independent control with continuity of service
The bank already used Avaloq. The program's task was to separate a shared service arrangement. The signed separation letter distinguished legal separation of contracts and license ownership from technical separation of databases, applications, infrastructure and access rights. Both were necessary for the bank to operate on its own. Continuing service depended on knowing what the bank owned, what the supplier operated and which permissions the other party to the arrangement could keep.
Data sovereignty here concerned authority, permitted access and oversight across jurisdictions as well as storage location. The customer-data target was the hosted core. Moving identities into that environment required changed access conditions, bank-controlled user authorization and outsourcing and legal review.
02 / Inside the system
Two client views and a changed access boundary
The June 2018 as-is design placed real customer names, addresses, account holders and powers of attorney in AMBIT/CIM, the bank's local client system. Avaloq, in the hosted core-banking service, held anonymized accounts, pricing and transactions. Account opening had no automated link between the systems; customer statements required identifying information from the local system to be combined with core output.
The target design added a richer customer model in the core: Business Partner, real Person and Address objects, with roles and authorities attached to the relationship. It connected the identity needed for compliance, reporting and multiple e-banking users to the financial account view. The bank controlled user-profile grants, including supplier access.
Service separation and data consolidation were related workstreams with different tasks. Separation came with e-banking under bank-controlled access. Data consolidation was a separate workstream of mapping, manual migration, reconciliation and user acceptance testing for existing customers.
- Local customer view
- AMBIT/CIM: identities, addresses, account holders and powers of attorney in the bank's local client system.
- Hosted banking view
- Avaloq: existing accounts, pricing and transactions in the hosted core, enriched with real Person and authority objects.
- Customer-service layer
- AFP e-banking for customer access; trading and payment activation handled separately.
- Adjacent batch design
- PAIN.001 payment input and asynchronous PAIN.002 interface feedback; execution followed banking workflow.
03 / Inside the system
Migration workflow: map, enrich, reconcile and accept
Supplier object-model specialists and bank staff agreed the target setup and field mapping before migration. A common key linked the existing records; target objects and attributes had to be available before the bank entered missing Person, Address, role and authority data. The specification limited this migration to existing clients.
The design called for two migration cycles and quality checks, followed by the bank's source-to-target comparison, UAT and cutover. A clean reconciliation file and correctly populated target objects were explicit acceptance criteria. Full Person Object Model 2 implementation belonged to a separate project; this scope prepared compatible entities rather than replacing the entire model.
December discussions favored manual entry over preparing and refining an automated bulk input, weighing quality and time. That decision created capacity and training obligations. When a person, address or authority did not match the source, correction and renewed comparison belonged in the migration process before acceptance.
A worked example
Example migration: an account holder and an authorized representative
Example with invented data.
01 / SourceIdentify the existing relationship
The local customer record holds the account holder, mailing address and a representative's power of attorney. The hosted account is linked through the existing common key. The mapping does not create a new account.
02 / ModelAgree the target persons and authorities
Bank staff and object-model specialists map the real persons and addresses to the Business Partner and define the representative's role. Target attributes must exist before entry begins.
03 / MigrationEnter and compare
Bank staff enrich the target objects and compare the person, address and authority against the source through the specified migration quality cycles. The supplier's configured model does not replace this banking check.
04 / ExceptionCorrect an authority mismatch
If the representative's authority differs between source and target, the record requires correction and another comparison. This illustrates the acceptance criterion.
05 / AcceptanceComplete the bank's migration checks
The bank verifies the reconciled relationship during UAT before the scoped cutover decision. Correct customer migration does not itself authorize trading, payment execution or a later onboarding release.
04 / Inside the system
Keep custody, customer access and payment execution distinct
Custody and brokerage service arrangements had their own contractual and operating tasks. Custody-contract completion was a material dependency in the steering plan. These relationships concerned the bank's ability to run its services, independent of the customer-data migration and of the platform supplier.
AFP provided the e-banking layer. Trading and payment features were activated separately from e-banking access. The adjacent payment-loader design used PAIN.001 batch instructions and PAIN.002 acceptance or error feedback. Feedback was asynchronous and described interface acceptance, while execution remained subject to the outgoing payment workflow, including approval and funds checks.
External account onboarding was another interface scope, with its own testing and bank validation. Each adjacent capability had its own operating decisions and acceptance tests, separate from the service separation.
05 / Inside the system
Choose the boundary before choosing the migration mechanism
Three decisions shaped the operating design: preserve service continuity while separating ownership, consolidate the customer view under controlled access, and make bank validation explicit before accepting migrated data. Each choice exchanged one kind of complexity for another.
- Decision 01
Separate the service arrangement around an existing core
Split legal service and license ownership together with technical access and common-platform responsibilities.
The bank needed to continue receiving services while operating on its own.
Trade-off. Continuity required coordination across bank leadership, the other party to the shared arrangement, advisers and the outsourcing provider; a contract change alone did not deliver technical independence.
- Decision 02
Consolidate customer identity under controlled hosted access
Move real customer identity and authority relationships into the hosted core model.
A single customer view reduced duplicate entry, alignment work and reporting complexity once access conditions changed.
Trade-off. Hosted identity data made profile authorization, outsourcing oversight and migration quality consequential.
- Decision 03
Prefer checked manual migration for the bounded initial scope
Use bank-led manual enrichment with two cycles and quality checks for existing customers.
Steering discussion favored quality and timing over preparing and refining a bulk automated input.
Trade-off. Manual transfer required trained capacity and reconciliation.
06 / Inside the system
Evaluate technical completion and banking correctness separately
The migration specification supplied concrete checks: source-to-target reconciliation, correctly populated customer objects and UAT. The payment specification distinguished valid loaded instructions, anomaly detection, error feedback and the outgoing payment workflow. These were the acceptance requirements.
Supplier completion of an interface and bank checking of the records it created were separate steps. Steering called for normal and failure cases and an accountable bank validator. The team assigned responsibility for field validation, failure cases, procedures and training alongside supplier deliverables.
- What defined the separation scope?
- The signed August letter required legal separation of contracts and licenses and technical separation of common-platform and access responsibilities, with continuity of service.
- What made a migrated relationship acceptable?
- Agreed mapping, prepared target objects, two quality cycles, source-to-target comparison and bank UAT were specified.
- Who checked the banking data?
- Bank staff. In December, steering distinguished supplier technical completion from the bank's field checks and failure-case validation.
- Which capabilities had their own activation path?
- Trading and payment features, existing-customer migration, and later onboarding and mobile work. Each had its own testing and operating decisions, separate from the service separation and e-banking.
- Did external hosting remove institutional control?
- No. The target design assigned user-profile authorization and outsourcing oversight to the bank while the customer data stayed in the hosted core.
07 / Inside the system
Delivery crossed institutional and supplier responsibilities
PIB Technology led the program. Bank leadership carried service ownership and commercial decisions; a delivery adviser coordinated methodology, technical sequencing and operating work. Platform and application suppliers delivered their own components. Supplier expertise helped define the customer model; the bank kept responsibility for the customer relationships entered into it.
Central-register and operations staff carried customer mapping and checking. Credit, brokerage, finance, risk and compliance contributed the processes required to use those records safely. Training, procedures and custody arrangements therefore belonged in the delivery plan alongside configuration and interface milestones. Steering made those interdependent responsibilities visible in one plan.
The people around the workflow.
- Bank leadership and the other party to the shared arrangement
- Service separation, independent ownership, contractual responsibilities and defined approvals.
- Delivery adviser and platform suppliers
- Program coordination, target-model design, environments, hosted services and component delivery.
- Central register and operating teams
- Customer mapping, manual enrichment, reconciliation, training and operating acceptance.
- Risk, compliance and assurance
- Authorized access, control procedures, outsourcing oversight and review of customer-data correctness.
- Custody and brokerage service owners
- Separate contracts, operating arrangements and readiness for the bank's custody and investment services.
Technology and integrations
Services in the workflow.
- AvaloqExisting core-banking platform
Hosted core platform, separated alongside e-banking and bank-controlled access.
Core banking platform
The design principle
Define who owns the service, who may access the data and who accepts the banking result at every handoff.