It is possible to transfer ICA/BINs from your existing Issuer processors to CLOWD9 to take advantage of CLOWD9s unique features.

Depending on the use case or number of existing active in-market cards, there are several types of Issuer Processor migration that can be considered, some of which require data transfers between your existing Issuer processor and the CLOWD9 platform, some of which require a new BIN or recard rather than a transfer of data.

The decision as to the most appropriate transfer/migration is likely to be driven by the need to consider:

• the number/profile of existing active cards/history/balances that might been to be migrated,
• impact to the existing card base,
• impact and risk to the correct operation of the portfolio while the migration is in progress,
• volume of any existing card stock,
• and the commercial and operational considerations of the migration activities/period.

If transferring a BIN between Issuers at the same time, there will be additional project elements to consider between the Issuing parties but no real impact on the data migrations.

Its important to note that key risks associated with migrations are mitigated by CLOWD9s default architecture and use of native cloud features.

For example, the addition in a short period of time at a migration cutover of significant numbers of accounts with the associated immediate uplift in transaction volumes will cause instant capacity problems for traditional processors, who will not have been able to predict the exact behaviours of their production platform, systems, databases and performance requirements in advance even if using modelling/capacity planning against pre-production systems.

CLOWD9s instant ability to scale in immediate response to new load resolves this issue, massively de-risking the migration activities.

Option 1 BIN Transfer, keeping your existing cards :

Where the requirement is to migrate a portfolio of existing live card accounts on the current ICA/BIN from an incumbent processor to CLOWD9 without impact to the existing cardholder experience.

Existing active cardholders will keep their existing card and will see no impact to their user experience during the course of the migration.

Any existing/pre-personalised card stock is still valid

Data migration is coordinated between incumbent processor and CLOWD9 (PAN/balances/transaction history etc)

On an agreed date scheme traffic is switched to the CLOWD9 endpoint.

Some risk due to the cutover point in time activities, no impact to existing cardholder experience.

Pros : Existing BIN continues. No re-card required. Transparent to existing cardholders. Data can be migrated as a series of small deltas as the cutover date approaches to minimise risk. Any existing plastic stock at can be used.

Cons : Risk due to nature of cutover/traffic switch event. Co-ordination and particularly key management/sharing activities between processors are critical to ensure existing cards can be supported. Old Issuer name preprinted on existing card stock may need a waiver to be able to continue to use it. Existing processor will charge for supporting the migration activities.

Option 2 : New BIN, re-issue cards on a new BIN on current card expiry or on zero balance:

This represents the simplest form of portfolio migration and presents the lowest migration risk to cardholder activity.

It is good for smaller portfolios or portfolios where the existing active cards have short lifespans.

The process is to leave existing active cards to expire or be closed as balances are reduced to zero on the current BIN/platform and then issue replacement accounts/cards on the new BIN on the CLOWD9 platform.

Over time the portfolio will naturally terminate on the existing platform and full issuance will complete on the CLOWD9 platform.

Pros : little/no data migration required, no cardholder impact, low operational risk. Good where existing cards have a short lifecycle and so existing portfolio will cycle out quickly. No or low support required from existing processor.

Cons : New BIN required. Period to complete migration = time for existing accounts/card to expire, operating across 2 separate platforms during the period of the migration. Any existing plastic stock can be used but would be on the OLD processor until old card stock is exhausted.

Option 3 New BIN, re-card on new BIN and cutover:

This represents a lower risk for portfolios where there are numbers of existing active cards with balance and history to be migrated but does require re-carding.

Over a period of time before the cut-over to CLOWD9 issue new inactive cards on a new BIN from the CLOWD9 platform to any existing active customers.

Manage and complete data migration (balances/transaction history etc) from the incumbent processor to the CLOWD9 platform.

Co-ordinate a date at which the new cards are active with balances available, and on which the old platform cards become inactive.

Stop scheme traffic to old BIN/cards, start scheme traffic to new BIN/cards.

Low risk to existing cardholder spend activity, some impact to the existing cardholder experience as they will have to switch from old to new plastic at an agreed point in time.

Pros : medium risk, data can be migrated as a series of deltas as the cutover date approaches, clear strategy/timing for old vs new cards, data migration required.

Cons : New BIN and re-card required, existing cardholder message management around managing their old vs new cards and cutover date. Any existing plastic stock can not be used. Post migration management of old BIN until it can be completely closed. Existing processor will charge for supporting the migration activities.